Cześć! Poszukuję wsparci gdyż powstał mętlik w głowie. Mam program, który komunikuję się z modułem GSM, używa wielu globalnych tablic, funkcji operujących na strumieniach typu strcpy, strncpy, strstr, strtok, poniżej wklejam większość deklaracji dużych zmiennych:
a to kawałek programu:
Bardzo proszę o wskazanie najważniejszych problemów/ potencjalnych źródeł błędów i wycieku pamięci. Dodam, że procesor usypia się regularnie a po każdym obudzeniu celowo resetuję go za pomocą WDT (aby wyczyścić RAM). Niestety najwyraźniej błędy trafiające się nawet po wielu dniach pracy powodują że dochodzi do wycieku przed uśpieniem po czym program już nie wstaje (lub wstaje tylko za pomocą jednego z dwóch różnych przerwań zewnętrznych).
Z tego co zdążyłem doczytać:
1) punkt 3.2 https://ww1.microchip.com/downloads/en/Appnotes/doc8453.pdf aby nie używać zmiennych globalnych (program przerabiałem wiele razy - były również największe tablice lokalne), jeżeli tablica jest globalna to od razu jest zajęty ram na jej alokację, jeżeli jest lokalna to ram początkowo nie jest zajęty a na stos odkładana jest ta tablica w momencie wywołania funkcji po czym po powrocie jest zdejmowana (zwalniany stos) więc wydaje się to faktycznie lepszym pomysłem.
2) Jeżeli używam strncpy a w src na pozycji 'n' nie ma znaku '\0' to znak ten nie zostanie dołączony do dst, jeżeli dalej wykona się kolejne operacje na stringach to mogą one nie działać prawidłowo.
3) Próbowałem sprawdzić zajętość RAM'u ale ciągle dostaje wynik 0, użyłem funkcji z pliku stackmon.c z https://www.elektroda.pl/rtvforum/topic1197789.html
A użycie:
Sprawdzałem w symulatorze i w obszarze data IRAM widzę znak canary czyli błąd musi leżeć w funkcji liczenia zajętości, tak?[/b][/b]
Dodano po 1 [godziny] 6 [minuty]:
Przeniosłem deklarację StackPoint z .int1 do .int3 i program zaczął wyświetlać 'jakiś' wynik
void StackPaint(void) __attribute__ ((naked)) __attribute__ ((section (".init3")));
Program idąc spać wyświetla: STACK=1061 (czasami STACK=1059), wynik kompilacji to: Data Memory Usage : 898 bytes 43,8 % Full
text data bss dec hex
13494 339 570 14403 3843
Kod: C / C++
a to kawałek programu:
Kod: C / C++
Bardzo proszę o wskazanie najważniejszych problemów/ potencjalnych źródeł błędów i wycieku pamięci. Dodam, że procesor usypia się regularnie a po każdym obudzeniu celowo resetuję go za pomocą WDT (aby wyczyścić RAM). Niestety najwyraźniej błędy trafiające się nawet po wielu dniach pracy powodują że dochodzi do wycieku przed uśpieniem po czym program już nie wstaje (lub wstaje tylko za pomocą jednego z dwóch różnych przerwań zewnętrznych).
Z tego co zdążyłem doczytać:
1) punkt 3.2 https://ww1.microchip.com/downloads/en/Appnotes/doc8453.pdf aby nie używać zmiennych globalnych (program przerabiałem wiele razy - były również największe tablice lokalne), jeżeli tablica jest globalna to od razu jest zajęty ram na jej alokację, jeżeli jest lokalna to ram początkowo nie jest zajęty a na stos odkładana jest ta tablica w momencie wywołania funkcji po czym po powrocie jest zdejmowana (zwalniany stos) więc wydaje się to faktycznie lepszym pomysłem.
2) Jeżeli używam strncpy a w src na pozycji 'n' nie ma znaku '\0' to znak ten nie zostanie dołączony do dst, jeżeli dalej wykona się kolejne operacje na stringach to mogą one nie działać prawidłowo.
3) Próbowałem sprawdzić zajętość RAM'u ale ciągle dostaje wynik 0, użyłem funkcji z pliku stackmon.c z https://www.elektroda.pl/rtvforum/topic1197789.html
Kod: C / C++
A użycie:
Kod: C / C++
Sprawdzałem w symulatorze i w obszarze data IRAM widzę znak canary czyli błąd musi leżeć w funkcji liczenia zajętości, tak?[/b][/b]
Dodano po 1 [godziny] 6 [minuty]:
Przeniosłem deklarację StackPoint z .int1 do .int3 i program zaczął wyświetlać 'jakiś' wynik
void StackPaint(void) __attribute__ ((naked)) __attribute__ ((section (".init3")));
Program idąc spać wyświetla: STACK=1061 (czasami STACK=1059), wynik kompilacji to: Data Memory Usage : 898 bytes 43,8 % Full
text data bss dec hex
13494 339 570 14403 3843
