Svenska ElektronikForumet

Utvecklar lite på ovanstående processor, använder CoIDE och Codesourcerys GCC som toolchain.

Jag använder inte värst mycket minne utan uppskattningsvis max 1k eller så, av 20k som finns.
Det enda programmet gör är att läsa av en touch-kontroller via SPI och göra lite matte av den datan, styra en färg-TFT utan att lagra i RAM vad den visar, utan den styrs i blindo. Sen så tickar en RTC också, men det är i princip allt, inget som tar nämnvärt mycket minne.

Det som händer är att när jag nu deklarerar några nya variabler så försvinner de senast deklarerade variablerna, oftast så försvinner X-koordinaterna från touchen. Och kör jag debuggern och kollar alla minnesplatser så mycket riktigt ligger där data i alla RAM-platser.

Kan inte gärna lägga upp all kod då det är ett par tusen rader kod utspritt på typ 15 filer, men är det något specifikt någon vill se kan jag givetvis visa upp.

Jag noterade att efter kompilering så läggs de skapade filerna i /debug/-mappen, jag vet inte om det ska vara så eller den typ bygger för debugging eller liknande? Hittar inga inställningar för det utöver att man kan trycka för att starta debugging och då kompilerar den, flashar det nya programmet och startar debuggingen. Men normalt så trycker jag bara "Build" och ingen debugging startas så den borde ju bygga för normalt då, tycker jag.

Tips på vad jag kan kolla eller några tänkbara nybörjarfällor när det gäller minnesanvändning?
Använder inga tunga funktioner som printf() eller liknande.

Kolla MAP-filen, där visas ju var alla data läggs. Borde inte länkaren varna ifall all RAM används? eller är det stacken som växer sig för stor?

Hm, vad jag kan se i MAP-filen så är där bara de globala variablerna, inte de som är privata i funktioner..
Inte en aning om den borde varna, det kan man tycka, men jag är ny när det gäller ARM så.

Kanske kan vara stacken... Tips på något vis att kolla det eller så?
Förstår dock inte varför den skulle fyllas..

Dom lokala variablerna ligger just i stacken. De allokeras i början av funktionen. Stacken kan fyllas ifall någon funktion anropas rekursivt. Eller om helt enkelt summan av alla lokala variabler blir större än den del av RAM som används som stack. För att kolla om stacken fylls skulle du kunna använda debuggern för att fylla stacken med t.ex. 0xAA, och sedan kolla om alla 0xAA byts ut till annan data, när programmet körs. Hur stor del av RAM som används som stack borde stå i länkfilen.

Jag tycker felet verkar osannolikt, och gissar på felet är något annat, t.ex. optimering, att variablerna läggs i register istället för i RAM, eller att de inte allokeras alls. Vad menar du med att variablerna "försvinner"? Du behöver beskriva problemet mer utförligt.

Om du låter funktioner returnera pekare till variabler som deklarerats inuti funktionen (och hamnat på stacken) så skulle det kunna bli såna fenomen som att värden "försvinner"/ändras när andra funktioner lägger beslag på stackutrymme.

För mig låter det som att du har en minnesläcka.
Några saker mans kulle kunna göra är:
1. fundera genom vart du använder dig av pekare i koden och verifiera att du skriver på rätt ställen och att du kontrollerat att pekarna har rimliga värden.
2. kolla i map-filen vilka variabler som ligger ovanför, om du har någon array där kan det vara värt att kolla att man håller sig inom index.
3. Lägg in variabler i minnet, jämnt utspridda med kända värden, t.ex börja och avsluta arrayer med värdet 0xAA55. därefter lägger du in en liten kodsnutt som kontrollerar om dessa värden ändrar sig. då är det lättare att hitta vart i koden det börjar gå fel.
5. skriv en liten snutt som kollar stackpekaren. har för mig att den ligger på register 12 eller 13 eller liknande på arm. om den ökar i värde för varje varv i koden är det nått som är lurigt. Om man t.ex använder sig av goto kommandon i koden kan man lätt missa en "retur" från en subrutin och då flyttas inte stackpekaren tillbaka. En annan fälla är recusiva funktioner som kallar på sig själva.
6. kör SPLINT eller MISRA eller annat kodgransknings verktyg som varnar ifall man använder oinitierade variabler eller kör recursiva anrop.

Har tagit en liten paus från det här men är igång igen nu!

Tänkte börja med förslaget att kolla stackpekaren men får inte ihop det. Hur tusan kollar jag den genom C?
Hittar en del exempelkod i Assembly men jag får inte ihop det med inline-ASM heller (Saknar helt kunskaper om ASM i ARM (No pun intended)).

Går det att läsa register med debuggern?
Borde gå att prova dangrafs tips genom att sätta en brytpunkt i main-loopen, och kika ifall stackpekaren har samma värde varje varv.

Givetvis, betydligt smidigare än att skriva en funktion för att visa det på displayen.

Den står stadigt på 0x20000654 varje varv, så det är åtminstone inget som fyller på den hela tiden. MEN, det verkar vara farligt lite minne ledigt i stacken, då den enligt MAP-filen sträcker sig från 0x20000288 till 0x20000688, bara några få byte kvar. Och då gör den alltså i princip ingenting när jag läser av den, det är inte i någon funktion eller så alls, så den borde stå väldigt mycket lägre. Säkerligen så att stacken fylls så fort någon funktion med lite privata variabler drar igång!

Då är bara frågan vad som ligger i stacken...

Kan du inte öka stacken till typ 2k då (i länk skriptet)? 1k kan fort bli lite, särskilt om man använder lite newlib-saker.

MEN, det verkar vara farligt lite minne ledigt i stacken

Stackpekaren brukar initieras på högsta adressen, och växa nedåt, så jag tror du har gott om utrymme kvar.

Om du testar att fylla 0x20000288 till 0x20000654 med något värde (typ 0xAA), sedan kör ett varv, och sedan tittar på stacken, kan du se hur långt ner stackpekaren gått under varvet.

Åh tusan, på så vis!

Då kan man nog säga att det inte är något som äter upp stacken stegvis i alla fall.
Men, det kan ju vara så att någon funktion tar löjligt mycket på något vis. Vore intressant att testa att utöka stackens storlek, kollade i link.id-filen men hittade inget om just storleken på stacken.

Liten uppdatering på den här tråden. Lagt projektet på hyllan ett tag men råkade av en händelse hitta här om dagen hur man väljer stack-storlek, provade att både två- och tredubbla den utan någon skillnad så nix, det är nog inte därför.

Får sätta mig i debuggingen på allvar någon dag och försöka hitta något mönster eller liknande på problemet..

Edit: Och om någon undrar så gör man det (vet inte om det är likadant i alla miljöer, men i alla fall i CoIDE) i startup_stm32f10x_md.c

ok, bra att veta.
När jag använder codesourcery och GCC ändrar jag storleken stacken i länk-scriptet. För mig används C-startup enbart till att initiera variabler och sätter upp miljön innan man hoppar in i början på main.

Hur kan du vara säker på att det är RAM-slut? (Inte hundra på att det hade varit min första slutsats om jag suttit med samma problem )
Jobbar du mycket med pekare?
Om du startar upp programmet, händer detta redan första iterationen eller börjar det hända efter några tusen iterationer?

Kan du dela med dig av lite kodstycken: De variablerna som försvinner (deklarationer) och när de försvinner?

Annars, om du har inkluderat förkompilerade bibliotek, kontrollera att de är kompilerade för samma arkitektur och inställningar som du själv använder. Inte alltid kompilatorn säger till om detta!

Borde ju inte ha med saker att göra, men prova "GNU Tools ARM Embedded" om du får slut på ideer, det är ju den coocox rekomenderar har jag för mig.