STM32F4DISCOVERY stackpekare

[SvenW]

Ingen fråga här, bara en liten men viktig observation för er som
leker med STM32F4DISCOVERY-kortet:

Håll koll på stackpekaren!
Det går köra program i RAM även om man 'glömmer' att strappa bootpinnarna.
BOOT0 och BOOT1(PB2) skall annars normalt strappas höga i det fallet.

Men om man glömmer detta så fungerar det ändå sånär som på att
stackpekaren initieras fel. Stacken kanske hamnar i kodsegmentet med många
konstigheter som följd.
Det kan lösas om man sätter SP explicit i startupfilen eller
att man programmerar flashminnet minst en gång.
Eller strappar bootpinnarna rätt.

Jag har spenderat timmar med att jaga buggar innan jag upptäckte detta.
Till och med slängt ett nytt kort i tron att det var trasigt!
Så håll koll på stackpekaren!

[mri]

Jag förstår inte riktigt problemet eftersom jag inte dykt såhär djupt i den här processorn, men generellt, varför skulle man *inte* explicit initiera SP i startkoden? Jag menar, nog är det ju i startkoden man "placerar" stacken där man vill lägga den... eller?

[SvenW]

Visst. Jag undrar också varför SP inte initieras i startupfilen. Man drar sig ju för ändra i 'system'-filer eftersom det ofta finns en anledning till att det är som det är.
SP ligger annars först i avbrottsvektorn, men den tar SP från 'fel' avbrottsvektor (från flashminnet) om man inte strappar BOOTpinnarna rätt.
Märkligt nog fungerar det i övrigt även om man glömmer strappa.
Det är ju väldigt bekvämt för nybörjaren att bara ansluta USB och köra igång kortet, ladda program i RAM och sedan testköra utan att behöva läsa på om BOOTpinnar.
--- ända tills att spökerierna sätter igång. Tråkigt om man lägger av bara för en sådan sak!!!

[bearing]

Detta får mig direkt att minnas på en tråd om misstänkta stackproblem med STM32 som jag skrivit i:
http://elektronikforumet.com/forum/view ... =7&t=61761

Nu efter att ha hittat den och skummat igenom igen är jag inte längre så säker på att det här är problemet. Vad tror du?

[Klas-Kenny]

Svarar i den här tråden istället, känns mest relevant.

Den koden och hårdvaran jag körde då är skrotad, så nu kan jag tyvärr inte testa igen. Men jag kollade på utvecklingskortet jag använde, BOOT1 och BOOT0 är båda dragna låga.
Den nya mjukvaran (Nästan samma men utan ett par funktioner, omskriven från grunden) är inte riktigt lika komplex (ännu, någon gång hoppas jag att få tummarna ur och skriva klart mjukvaran till den), och på den nya hårdvaran används BOOT1 som vanlig utgång, men BOOT0 är fortfarande dragen låg.
Enligt datablad ska det få den att boota från Flash, så det ska väl inte kunna vara problemet i mitt fall...

Kan bli intressant att se om mitt problem återkommer den dagen programmet får bli lite större igen.

[SvenW]

Läste igenom Klas-Kennys tråd.
Nej, jag tror inte det är samma problem, även om symptomen är likartade.
Det kan finnas andra orsaker. Vilken pekare som helst kan orsaka liknande problem.
Klas-Kennys verkade ha koll på stacken.

Dock försår jag inte varför man inte lägger stacken högst i RAM, i båda våra fall.
På mitt kort blev den 0x2000c80 har jag för mig. Skulle vara 0x2020000.

Annars kan kompilatorns optimering plocka bort en del variabler så att de inte syns i debuggern,
men om jag förstod rätt var det inte det tråden handlade om.