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

Atmega32 - błędne odczyty z pamięci po załadowaniu programu >20kb

j3rry 22 Kwi 2008 14:35 1824 21
REKLAMA
Zgłoś naruszenie prawa
Odpowiedz | Nowy temat
  • #1 5064659
    j3rry
    Poziom 10  
    Posty: 33
    Witam
    Mam układ Atmega32 w którym wszystko chodziło do czasu kiedy nie załadowałem na niego programu który był większy niż 20kb po tej operacji uP zaczął wariować ;/ tzn.. UART wysyła krzaki (stringi z programu które są zaszyte w SRAM i nie powinny być wyświetlane w takiej formie) jakby ze SRAM odczytywał jakoś tak chaotycznie ;/

    używam avr-gcc 4.1.2 + linux + stk300
    uP był programowany ok 600 razy ale nie wiem czy to może mieć aż taki duży wpływ;/
    a dla jasności program jak miał 19kb to chodził idealnie bez żadnych zastrzeżeń...

    Czy któryś z kolegów spotkał się już z takim problemem??
    F&Home: inteligentna automatyka budynkowa, która łączy technikę, wygodę i bezpieczeństwo [sponsorowane]
  • REKLAMA
  • #2 5064735
    Dr_DEAD
    Poziom 28  
    Posty: 829
    Pomógł: 126
    Ocena: 3
    Dobrą praktyką jest umieszanie w kodzie na samym początku procedury testującej cały RAM oraz procedury sprawdzającej sumę kontrolną KODU (chodzby najprostszą - sume bajtów).

    Ale pewno się okaże że to jednak błąd w programie.
  • #3 5064738
    nsvinc
    Poziom 35  
    Posty: 2870
    Pomógł: 262
    Ocena: 88
    tak, to jest norma. Ja mialem podobny przypadek, tyle ze program wiekszy niz 22kB na medze32 wogóle nie chciał działać wg założeń, a jesli byl w okolicach 20kB to chodził.
    Nawet przeszukiwanie datasheeta nie pomogło.

    Nowsze megi32 juz nie mają takich trzasków, i mozna załadować do nich całe 32kB...

    Moze byc to tez kwestia fusebitów. CHodzi szczególnie o BOOTSZ i BOOTRST, podaj co tam masz zaprogramowane
  • #4 5065718
    elektryk
    Poziom 42  
    Posty: 11029
    Pomógł: 439
    Ocena: 240
    A może to problem ze stosem? Prześledź najlepiej pod jakimś debugerem kiedy się nadpisuje końcówka pamięci.
  • #5 5066518
    j3rry
    Poziom 10  
    Posty: 33
    Aktualne ustawienia fusebitów:
    Atmel AVR ATmega32 is found.

    Fuse Low Byte = 0xef
    Fuse High Byte = 0xc9
    Fuse Extended Byte = 0xff
    Calibration Byte = 0xb4 -- Read Only
    Lock Bits = 0xff
    BLB12 -> 1
    BLB11 -> 1
    BLB02 -> 1
    BLB01 -> 1
    LB2 -> 1
    LB1 -> 1

    czyli BOOTSZ1 i BOOTSZ2 = 0
    a BOOTRST = 1

    elektryk sprawdzę to z tym stosem ale nie sądzę ponieważ funkcje które dopisałem wykonywane są na końcu natomiast program wykrzacza się od począdku....
  • #6 5066577
    Zajc3w
    Poziom 14  
    Posty: 104
    Pomógł: 1
    Czyli masz ustawione 4096 bajtów na bootloader. Spróbuj ustawić BOOTSZ1 =1 i BOOTSZ2 = 1 będzie tylko 512 bajtów, ale to chyba nie to - masz przecież 28KB na program....
    Może optymalizator sie kopie powyżej 20KB
    Jaką masz wersję avr-libc?? W standardowych repozytoriach bywaja dość stare. np w Ubuntu 7.10 jest GCC 4.12 i AVR-libc 1.4.2 a najnowsze jest 1.6.2
  • #7 5066675
    j3rry
    Poziom 10  
    Posty: 33
    Zajc3w jutro zmienię na 512b ale nie sądzę by to było problemem....

    wersja avr-libc-1.6.1
  • REKLAMA
  • #10 5066806
    j3rry
    Poziom 10  
    Posty: 33
    Linux: Slamd64 (slackware 64bit)

    A już chyba doszedłem bo poskracałem program maksymalnie jak się tylko dało tzn. wykorzystywanie przez program pamięci SRAM i widzę że pomogło :) (tylko niestety program nie ma pełnej sprawności ;/ ) ale nie mogę uwierzyć bym 2k pamięci zajmował...
    czy ktoś może mi podpowiedzieć jak to sprawdzić ??


    PS: chyba czeka mnie jednak przesiadka na ATMega128 :/
    PS2: Balu nie chciał bym cię zanudzać 100k tekstu :P
    "AT(Siemens ME45), GPRS(PPP), MD5, i jeszcze kilka modułów":P

    Dadane: 22 Kwi 2008 23:12
    A jednak nie działa :( uP nie stabilny teraz czasem idzie OK a czasem krzaki :( trzeba chyba zmienić procesor i będzie po problemie...
  • #11 5067067
    __Grzegorz__
    Poziom 30  
    Posty: 1406
    Pomógł: 194
    Ocena: 229
    Każdy kompilator powinien produkować pliki z podsumowaniem nt. wygenerowanego kody (pliki *.map).

    Tam możesz sprawdzić ile miejsca zajął Ci kod, zmienne, itd.....

    Dzięki temu sprawdzisz / zmodyfikujesz najbardziej pamięciożerne fragmenty kodu...

    Opowieści kolegów, że ATmel nagle wypuścił AVR-y które działają dobrze są bzdurą wynikającą z niewiedzy nt. programowania AVRów...

    Pozdrawiam.
  • #13 5067152
    j3rry
    Poziom 10  
    Posty: 33
    nie tak dużo ok 1300b SRAM-u jak dobrze odczytuje..
  • REKLAMA
  • #14 5067208
    tomus2k
    Poziom 27  
    Posty: 770
    Pomógł: 89
    Ocena: 216
    Stos ??? obsługujesz dość znaczne dane GPRS i pewnie masz za mało przydzielonej pamięci na stos a za duże zmienne .
    Dwa pamiętaj aby podczas przepisywania danych z RS nie przekraczać wielkości zmiennej co często się przytrafia przy transmisji GPRS bo tam idą znaczne stringi. Czy kwarc jest zabezpieczony kondensatorami , czy zasilanie dla telefonu jest oddzielne niż procesora czy masz kondek 100n zaraz na zasilaniu procka . Pamiętaj że GSM to 2W na max przy 900 i 1W przy 1000 a to przy niefortunnym ułożeniu ścieżek potrafi namieszać nawet w ramie procka. A i telefon może pobrać nawet do 1A podczas transmisji tak więc ważne aby zasilacz nie przysiadał.
  • #15 5068580
    Ch.M.
    Poziom 27  
    Posty: 1009
    Pomógł: 62
    Ocena: 15
    Skoro program działał przy mniejszych gabarytach to albo jest problem z programem albo z kompilatorem. Miałem podobna rzecz, tyle, że u mnie program źle działał tylko dlatego, że kompilator źle go w pamięci lokował przy podziale na podprogramy. Jak wrzuciłem wszystko w jednym ciągu to raptem zaczęło działać i nawet znalazły się dwa błedy których wcześniej nie wykrywało. Program w ASM co dziwniejsze :)
  • REKLAMA
  • #16 5076596
    cyberdar
    Poziom 31  
    Posty: 1465
    Pomógł: 161
    Ocena: 73
    Witam

    Niestety problem o jakim wspomniał Ch.M. występuje również w Bascomie. Jeśli program ma spore rozmiary a zbyt dużo poumieszcza się w podprogramach to są błędy w działaniu na samym uC przy czym kompilacja jest jak najbardziej ok.

    --
    pozdrawiam
  • #17 5077109
    __Grzegorz__
    Poziom 30  
    Posty: 1406
    Pomógł: 194
    Ocena: 229
    cyberdar napisał:
    Witam

    Niestety problem o jakim wspomniał Ch.M. występuje również w Bascomie. Jeśli program ma spore rozmiary a zbyt dużo poumieszcza się w podprogramach to są błędy w działaniu na samym uC przy czym kompilacja jest jak najbardziej ok.

    --
    pozdrawiam


    Oczywiście - nie ma to nic wspólnego z rozmiarami stosu... (cynizm)...

    Ludzie - myślcie !!! Nie piszę w BASCOM, ale głowę dam, że po zwiększeniu rozmiaru stosu (o ile to w ogóle możliwe, to nie C, ani asm)- problemy znikną jak za dotknięciem magicznej różdżki. Procesor się "naprawi"...
  • #18 5077515
    Balu
    Poziom 38  
    Posty: 4397
    Pomógł: 323
    Ocena: 48
    @__G__tak da się w bascomie zwiększyć stos...
    Jakbyś poza tym nie zauważył postodawca pisze a gcc:> To chyba bascom nie jest... no chyba,że nowa "lepsza" odmiana;)
  • #19 5077566
    michalko12
    Specjalista - Mikrokontrolery  
    Posty: 3394
    Pomógł: 462
    Ocena: 321
    j3rry napisał:
    nie tak dużo ok 1300b SRAM-u jak dobrze odczytuje..


    Ty wykorzystujesz 1300 a biblioteka może też troche potrzebować. Jakim adresem jest inicjowany wskaźnik stosu?
  • #20 5080326
    j3rry
    Poziom 10  
    Posty: 33
    A możesz michalko12 podać jak mogę to sprawdzić ??
  • #21 5082097
    michalko12
    Specjalista - Mikrokontrolery  
    Posty: 3394
    Pomógł: 462
    Ocena: 321
    j3rry napisał:
    A możesz michalko12 podać jak mogę to sprawdzić ??


    Jeśli nie korzystasz z własnego startup kodu wskaźnik inicjowany jest na samym poczatku programu w jednej z pierwszych sekcji "Init" Poczytaj sobie o tych sekcjach w dokumentacji avr-libc. http://www.nongnu.org/avr-libc/user-manual/mem_sections.html

    Masz kilka sposobów na sprawdzenie wskaźnika stosu.

    1. Załadować kod do jakiegoś symulatora, jedna z pierwszych linijek kodu jest ustawienie rejestru wskaźnika stosu. Będziesz to widział w rejestrach symulatora.
    2. sprawdzić plik z wylistowanym kodem, który jest generowany po kompilacji.
    3. Umieścić kod odczytujący i zapamietujący wskaźnik stosu w jednej z ostatnich sekcji "Init", a dalej gdzieś w programie wyświetlić zapamiętana wartość wskaźnika.
  • #22 5082543
    romario4
    Poziom 16  
    Posty: 138
    Pomógł: 17
    Ocena: 3
    j3rry napisał:
    Witam
    Mam układ Atmega32 w którym wszystko chodziło do czasu kiedy nie załadowałem na niego programu który był większy niż 20kb po tej operacji uP zaczął wariować ;/ tzn.. UART wysyła krzaki (stringi z programu które są zaszyte w SRAM i nie powinny być wyświetlane w takiej formie) jakby ze SRAM odczytywał jakoś tak chaotycznie ;/

    używam avr-gcc 4.1.2 + linux + stk300
    uP był programowany ok 600 razy ale nie wiem czy to może mieć aż taki duży wpływ;/
    a dla jasności program jak miał 19kb to chodził idealnie bez żadnych zastrzeżeń...

    Czy któryś z kolegów spotkał się już z takim problemem??

    Witam!
    A co programator na to ? Czy po weryfikacji zapisanego wsadu jest wszystko OK! Kiedyś miałem podobny przypadek z atmegą32L że gdy objętość kodu przekroczyła ( bodajże jakieś 18KB) to z programem zaczęły się dziać jakieś dziwne rzeczy, okazało się że uszkodzony była pamięć flash powyżej pewnego adresu, i program się wysypywał.
    Pozdrawiam.
Odpowiedz | Nowy temat
Zgłoś naruszenie prawa

Podsumowanie tematu

✨ Problem dotyczy mikrokontrolera Atmega32, który po załadowaniu programu większego niż 20 kB zaczął generować błędne odczyty z pamięci SRAM, objawiające się wysyłaniem nieczytelnych danych przez UART. Program o rozmiarze około 19 kB działał poprawnie, natomiast większy powoduje niestabilność. Dyskusja wskazuje na możliwe przyczyny takie jak błędy w programie, niewłaściwe ustawienia fusebitów (szczególnie BOOTSZ i BOOTRST), problemy z inicjalizacją i rozmiarem stosu, a także potencjalne uszkodzenie pamięci flash powyżej pewnego adresu. Zalecane jest testowanie całej pamięci RAM, sprawdzanie sumy kontrolnej kodu, analiza plików map generowanych przez kompilator, a także weryfikacja wskaźnika stosu i optymalizacja wykorzystania pamięci SRAM. Wskazano również, że niektóre starsze wersje Atmega32 mają ograniczenia w obsłudze programów powyżej 20 kB, a nowsze modele mogą nie mieć tego problemu. Poruszono także kwestie stabilności zasilania i wpływu modułów GSM na pracę mikrokontrolera. W przypadku braku rozwiązania sugerowana jest zmiana mikrokontrolera na model z większą pamięcią, np. Atmega128.
Wygenerowane przez model językowy.
REKLAMA