logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

problem ze stosem w AvrStudio

rpal 02 Mar 2010 14:23 1143 2
REKLAMA
  • #1 7773145
    rpal
    Poziom 27  
    Najpierw opiszę objaw, domniemaną przyczynę a potem poprosze o rade:
    Mam program który pożera mi większość RAM, głównie za sprawą dużych buforów między innymi na dane pochodzące z 2 UART-ów (atmega 162) i innych zadeklarowanych tablic. Generalnie wszystko jest OK jednak kiedy powięszam wielkość zajętej pamieci RAM , tak gdzieś do zużycia jej w 80% program się wysypuje i uruchamia od nowa. Jest tam też sporo funkcji i procedur które pochłaniają stos oraz kilka przerwań. Eksperymentowanie z zajętością RAM i próby doprowadziły mnie do wniosku że winą jest rozmiar stosu a w zasadzie jego aktualne położenie tzn. program skacze sobie do jakiejś procedury, zmienia się wskaźnik stosu. W tym czasie pojawia się przerwanie które zmienia dane w jakimś buforze które nieopatrzenie zostały zajęte przez stos, przerwanie się kończy a program idzie w diabły. W sumie poradziłem sobie w ten sposób że zrobiłem tymczasowy bufor który jest ładowany ze zmiennych z pamięci stałej. Jednak ma to ten minus że pochłania dla odmiany pamięć programu. Pytamie jest takie, czy poprawnie zdjagnozowałem problem a co najważniejsze czy AVRStudio ma mechanizmy aby wyłowić miejsce w programie przy którym stos włazi na dane a dane na stos. Komplilacja poza komunikatem o zajętości pamięci coś tam wprawdzie daje do myślenia jednak praca programu zwłasza przy zagłębianiu się w podprogramy i obsłudze przerwań wiele informacji nie daje poza tym że wychwyciłem restart programu dobrze by było zmonitorować stos. Debuguje Jtagiem. PZDR
  • REKLAMA
  • #2 7773438
    tmf
    VIP Zasłużony dla elektroda
    Wyglada jakby istotnie stos wchodzil zbyt nisko, co powoduje, ze jest nadpisywany przez zmienne. Skoro masz JTAG to sprawdz gdzie koncza sie zmienne - mozna to sprawdzic np. w pliku map, zakladajac, ze nie uzywasz sterty to w najbardziej zaglebionej funkcji ustaw breakpointa i sprawdz wskaznik stosu. Jesli jest nizej niz zmienne to masz odpowiedz. Warto tez przed uruchomieniem programu wpisac do SRAM cos charakterystycznego, to ci ulatwi sprawdzenie wizualne co sie dzieje. Skoro jak piszesz zmienne globalnie alokowane zajmuja ci 80% to na reszte specjalnie duzo nie zostaje. Kazde wywolanie funkcji lub przerwania to srednio kilkanascie bajtow na stosie + miejsce zajete przez zmienne lokalne.
  • #3 7774234
    rpal
    Poziom 27  
    No właśnie tego się domyślałem, rozumiem że ustawienie czegoś w rodzaju pułapki na wskaźniku stosu nie wchodzi w rachubę. Generalnie jest to sygnał że muszę popracować nad spoójnością całego programu i dać ram-owi nieco oddechu:(
REKLAMA