Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

AtMega8 - program o rozmiarze bliskim 8kB przestaje działać

MirekCz 19 Jul 2007 20:25 1599 13
  • #1
    MirekCz
    Level 35  
    Witam serdecznie,

    Mam mały problemik. Piszę program na AtMega8 i gdy jego rozmiar zbliża się do 8kB to program przestaje działać.
    Wg. testów wynika, że następuje to ok. 7350bajtu programu - większy program nie działa, mniejszy działa bez problemu (jedyne co zmieniam to wielkość bufora danych we flashu).

    Pytanie, co może to powodować?
    Pamięć rezerwowana we flashu?

    (fuse bity dotyczące bootloadera mam nie przestawiane)

    Dziękuje za pomoc
  • #2
    markosik20
    Level 33  
    Miałem kiedyś podobny problem i sprawa była związana z ustawieniami kompilatora (C dla 51) , oraz musiałem jeszcze raz przeanalizować dokładnie newralgiczne punkty programy (np: wykorzystanie stosu).
    W jakim języku masz napisany program?
    Rozumiem ze program "idzie w maliny" w jakimś konkretnym miejscu?
    Jeżeli tak warto to przeanalizować na symulatorze.
  • #3
    johny_w
    Level 21  
    A jesteś pewien, że ten bufor na 100% jest we flash'u? Pisząc bufor - sugerujesz że jest to tablica zmiennych, która na bierząco pośredniczy w wymianie danych. Jeżeli tak - bufor ten musi znajdować się w ramie. W przypadku AVR nie ma możliwości zapisywania do flasha z pozoimu programu (można to tylko zrobić z sekcji bootloadera).

    A co mówi kompilator na zajętość pamięci? Twój przypadek rzeczywiście bardziej wskazuje na zamazanie stosu niż przepełnienie flasha.

    pzd., JnS
  • #4
    MirekCz
    Level 35  
    Ten bufor ma 1024*2 bajty w pełnym rozmiarze.. daleko przekracza to rozmiar pamięci AtMegi.

    Jeżeli bufor zostawie 1024*2 a wywale inny kawałek kodu, to program działa ok. Jeżeli mam cały kod i bufor zmniejsze do mniejwięcej 1200bajtów to też działa ok.

    PS.Jak w GCC dla AVR można zobaczyć ile/jakiej pamięci jest zajęte na program/dane globalne itp?
  • #5
    johny_w
    Level 21  
    Ja korzystam z AVR Studio. Oczywiście piszę w C. Podczas kompilacji dostaję "raport" ile bajtów flasha, ramu i eepromu zużył program.

    Dodatkowo (w razie problemów) korzystam z wbudowanego symulatora. Można w każdym momencie zatrzymać program, sprawdzić zawartość pamięci, wartości zmiennych i stany wszystkich rejestrów uC.

    Ten symulator sprawuje się nieźle w stosunku do programów, które nie są uzależnione od danych wejściowych (jak np. dane z RS, klawiatura, itp.). W przypadku takich projektów stosuję JTAG. Jest to system pozwalający w każdej prawie chwili "wdarcie się" w pamięć i stan zmiennych rzeczywistego układu. Niestety mega8 nie posiada JTAG'a :(

    Jeżeli Twój kod nie jest tajemnicą - umieść go. Zobaczymy co jeste nie tak (ale już nie dziś :) )
  • #6
    markosik20
    Level 33  
    No nie nazwałbym buforem obszaru danych w pamięci programu. :wink: Do tego lepiej pasuje tablica (ze stałymi). Jeżeli deklarujesz taką tablice (podajesz jej wymiar) i nic w niej nie umieszczasz to kompilator może na to róźnie reagować (w zalażności od ustawień). Za każdym razem kiedy tablica zostaje zadeklarowana w pamięci programu trzeba w niej umieścić dane (podczas deklarowania tablicy), inna sprawa z pamięcią RAM ale jak mówisz problem dotyczy Flash'a.
  • #7
    andre65
    Level 13  
    Nie wiem, co miałeś na myśli pisząc:
    Quote:
    (jedyne co zmieniam to wielkość bufora danych we flashu)

    Dla mnie taka sprawa ewidentnie "pachnie" nakładaniem się segmentów zmiennych globalnych ze stosem danych lokalnych oraz stosem powrotów z wywoływanych funkcji.
    Generalnie kompilatory nie radzą sobie z automatycznym wyznaczaniem niezbędnych rozmiarów stosów i trzeba je ustawiać ręcznie w odpowiednich opcjach.
    Jak chcesz wiedzieć, co na co może "nachodzić", sprawdź w listingu zakresy deklaracji stosów oraz jakie zmienne z nimi graniczą. Sprawdź też, w którym kierunku wypełniają się stosy w Twoim kompilatorze i tam szukaj problemów.
    Pozdro
  • #8
    al555
    Level 20  
    Witam,
    to rzeczywiście będzie problem ze stosem.

    ande65: czy można w listingach z WinAVR/GCC sprawdzić jaki zakres zajmuje stos ( i jak bardzo będzie się powiększał) czy pozostaje tylko badanie pamięci RAM na działającym procku ( np. przez wstępne zapisanie zakresu pamięci jaki zajmuje w przybliżeniu stos a potem sprawdzanie które komórki zostały zmienione/zapisane przez odkładanie na stosie)

    Pozdrawiam
  • #9
    MirekCz
    Level 35  
    Niby wszystko pięknie, ale dlaczego to działa/nie działa jak zwiększam tablicę zadeklarowaną jako stałą i siedzącą w pamięci flash?
    Stos przecież nie siedzi we flashu...

    Przekompiluje to w AVRStudio to może coś nowego się dowiem...
  • #10
    ogr
    Level 15  
    Sprawdz czy przypadkiem nie masz ustawionego FUSE
    Boot Reset Vector Enabled

    Pozdrawiam.
  • #11
    MirekCz
    Level 35  
    Nie mam Boot Reset Vectora ustawionego.. zresztą próbowałem już w obie strony - on/off i nic to nie zmieniło.
  • Helpful post
    #12
    BoskiDialer
    Level 34  
    czasem problemem okazuje się niestała stała - tablice stałych można przypuszczać, że będą tylko w pamięci flash - przeważnie okazuje się, że kompilator owszem zapisuje sobie tablicę w pamięci flash, ale z początku programu kopiuje sobie ją do ramu - w ten sposób można się odwoływać do komórek takiej tablicy jak do zwykłej pamięci ram (przestrzeń). Może należało by oznaczyć, że tablica ma być tylko w kodzie programu? - szybkie szukanie:
    https://www.elektroda.pl/rtvforum/topic308467.html
    - trzeba dołączyć: #include <avr/pgmspace.h>
    - do deklaracji tablicy dodaje się atrybut "PROGMEM"
    - odczyt komórek za pomocą "PRG_RDB()".....

    ogólnie trzeba się pokręcić wokół tego, że kompilator umieszcza tablice stałych w pamięci ram.
  • #13
    MirekCz
    Level 35  
    Kolega BoskiDialer ma rację.
    Program po użyciu pgmspace działa już bez niespodzianek.

    Serdecznie dziękuje za pomoc.