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

Question

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

BoskiDialer · Accepted Answer

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.

markosik20 · Answer

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.

johny_w · Answer

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

MirekCz · Answer

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?

johny_w · Answer

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ś

)

markosik20 · Answer

No nie nazwałbym buforem obszaru danych w pamięci programu. 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.

andre65 · Answer

Nie wiem, co miałeś na myśli pisząc: 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

al555 · Answer

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

MirekCz · Answer

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...

ogr · Answer

Sprawdz czy przypadkiem nie masz ustawionego FUSE Boot Reset Vector Enabled Pozdrawiam.

MirekCz · Answer

Nie mam Boot Reset Vectora ustawionego.. zresztą próbowałem już w obie strony - on/off i nic to nie zmieniło.

MirekCz · Answer

Kolega BoskiDialer ma rację. Program po użyciu pgmspace działa już bez niespodzianek. Serdecznie dziękuje za pomoc.

johny_w · Answer

Jednak Twój bufor rzeczywiście siedział w ramie!?

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

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Podsumowanie tematu