[STM32F4][C/Eclipse] - Duża ilość danych jest źle wpisywane do SRAM

Cześć,
Używam stm32F407, Eclpisa z bleeding-edge-toolchain, projekt oparty no przykładzie freddiego oraz używam bibliotek StdPeriph_Drive.



Napotkałem dzisiaj na dziwny problem.
Tworząc tablice (uint32_t) 100-elementową program działa poprawnie. Gdy rozszerzę tablicę do 1000, program się zawiesza.
Kod okroiłem do inicjalizacji procesora i tej tablicy oraz zapisania do niej kolejnych wartości od 0 w górę (aby kompilator nie wyrzucił zmiennej). Niestety problem nadal występuje.
Podglądając pamięć w debuggerze okazało się że pierwszy element tablicy jest
zapisany pod adresem : 0x1FFF F410 i ma wartość 0xFFFF FFFF
Natomiast ostatni : 0x2000 03B0 i ma wartość 0xEC00 0000
Gdy tablica była 100-elementowa dane były zapisywane od adresu 0x20000000 w górę.


Czy ktoś jest w stanie wyjaśnić dlaczego te dane są zapisywane pod złym adresem (poniżej 0x2000 0000) oraz jak ten problem można rozwiązać.
Z góry dzięki

Dołączam konfigurację rcc oraz pętlę tworząca tablicę.

Twoja tablica jest alokowana na stosie, ktorego jest ograniczona ilosc (w skrypcie linkera mozesz ja zwiekszyc). Tworzenie duzych obiektow na stosie nie jest zbyt dobrym rozwiazaniem. Powinienes w takim przypadku uzyc tablicy globalnej lub zaalokowac ja dynamicznie (za pomoca malloc).

Rzeczywiście. Rozmiar stosu mam 1024 więc się przepełnia.
Dzięki.

Skoro stos ma rozmiar 1024B to pozostałymi 111kB SRAMu są nie używane? Co stoi na przeszkodzie na rozszerzeniu stosu na cały zakres pamięci?
Nie ma innego sposobu niż globalna zmienna? Czasami potrzebuję zapisać dużo danych tylko w obrębie jednej funkcji. Natomiast Malloc wydaje mi się armatą na muchy.

adelwis wrote:

Rzeczywiście. Rozmiar stosu mam 1024 więc się przepełnia.
Dzięki.

Skoro stos ma rozmiar 1024B to pozostałymi 111kB SRAMu są nie używane? Co stoi na przeszkodzie na rozszerzeniu stosu na cały zakres pamięci?
Nie ma innego sposobu niż globalna zmienna? Czasami potrzebuję zapisać dużo danych tylko w obrębie jednej funkcji. Natomiast Malloc wydaje mi się armatą na muchy.

A to problem zmienić ustawienia stosu? Tylko potem to problem opanować tak wielki stos.

Oczywiście stos zwiększyłem. Pytam się jakie problemy mogą wyniknąć ze zbyt dużego stosu oraz w jaki inny sposób niż malloc i global można "dostać się" do SRAM.

Poza stosem w SRAMie masz jeszcze przynajmniej:
- stertę - dynamiczna alokacja (malloc, new)
- sekcję data - wszelkie globalne i statyczne zmienne inicjowane jakąś wartością
- sekcję bss - jw. ale zerowane przy starcie programu
poza tym możesz sobie tworzyć własne sekcje, latać wskaźnikiem po pamięci i cokolwiek Ci przyjdzie do głowy.

Alokowanie dużej ilości danych na stosie niesie ryzyko, że się w tym pogubisz i przepełnisz stos wywołując kilka funkcji. A zamazywanie danych w pamięci przez stos jest... nieprzyjemne. Mały stos narzuca tu pewną dyscyplinę
Jak nie korzystasz z dynamicznej alokacji to możesz rozszerzyć stos na cały SRAM poza data i bss (patrz skrypt linkera).

adelwis wrote:

Co stoi na przeszkodzie na rozszerzeniu stosu na cały zakres pamięci?

Teoretycznie nic, kwestia konfiguracji linkera np. ld dla pic32 od niedawna używa całą dostępną pozostalą pamięć na stos a deklaruje się tylko rezerwację minimum stosu. Pomimo to, jak już zauważyli szanowani przedpiścy, wrzucanie takich dużych tablic (szczególnie w ISR) to zazwyczaj zły pomysł.

Dzięki wszystkim za pomoc. Zamykam temat.