MEGA 32 Stack-Crash?

[Marco G. (macro)]

Hallo Leute,

bin gerade dabei ein relativ grosses Programm für nen mega 32 zu
schreiben (bislang ca 10k flash voll).
Neuerdings gibt es neuerdings Probleme wenn ich zusätslichen code
einfügen will.
U.U. hängt sich der controller auf weil offensichtlich der stackpointer
zerschossen wird.
Ich programmiere mit pn und winavr in C und lasse das ganze auf studio4
mit jtag laufen.
Hat jemand ne Ahnung? Vielleicht ne Einstellung am compiler falsch?

[Peter Dannegger (Gast)]

Wirf einfach mal nen Blick ins *.map File.
In der Sektion .data stehen dann alle Variablen bis zur Sektion
.eeprom. Dann weißt Du wieviel noch für den Stack übrig ist bzw.
welches die größten Speicherfresser sind.


Peter

[crazy horse (Gast)]

da wird dir wohl kaum jemand helfen können, bei den Angaben...
Prinzipiell hat die Codegrösse erstmal nichts mit benötigter
RAM/Stackgrösse zu tun.
Rekursion eingebaut?
Assemblerteile eingefügt mit u.U. unterschiedlicher push/pop-Anzahl?
Kenne den WINAVR nicht, evtl. kannst du memory modell einstellen?? tiny
oder small?

[Marco G. (macro)]

Hallo Peter,

danke erstmal für den Tipp. Ich arbeite noch nicht so lange mit dieser
Entwicklungsumgebung, von daher hab ich da so meine Probleme bei der
Interpretation des .map-files. Ich schicke es einfach mal mit in der
Hoffnung du kannst mir da behilflich sein.

danke
marco

[A.K. (Gast)]

"weil offensichtlich der stackpointer zerschossen wird."

Wodurch ist das "offensichtlich"?

[Marco G. (macro)]

Hallo,

das sehe ich im disassambler-Fenster. Da springt der pc nach einer
subroutine ins Nirgendwo.

marco

[A.K. (Gast)]

Was bis zum Beweis des Gegenteils nicht so sehr auf einen defekten
Stackpointer als auf eine defekte Return-Adresse im Stack schliessen
lässt.

Kann es sein, dass in einer Funktion ein Puffer als lokale Variable
definiert wird? Im Mapfile tauchen die nicht auf. Möglicherweise wird
über das Ende des Puffers hinaus geschrieben, oder der Puffer ist
schweinemässig gross.

[Peter Dannegger (Gast)]

Laut map-File sind nur 267 Byte belegt von den 2kB, da ist also noch
massig Luft.

Ich würde mal auf nen falsch gesetzten Pointer tippen, der Dir den
Stack vergurkt.


Peter

[Marco G. (macro)]

Da habt ihr den Finger wahrscheinlich genau drauf.

Ich habe mir jetzt mal alle Felder genau angesehen. Da gibt es ein
statisches Feld mit 8 Elementen das im SRAM auf dem Bereich liegt in
dem der Stack residiert (>0x840).
Das array wird völlig banal im main deklariert und initialisiert und
ist vom Typ long int --> long int u[8];.
Wie kann das passieren?

marco

[A.K. (Gast)]

Du hast das Array in main vermutlich (implizit) als "auto" deklariert,
nicht als "static". Dann liegt es auf dem Stack und nicht im normalen
Datenbereich.

[Marco G. (macro)]

Kannst du das bitte etwas ausführlicher erleutern?
Bislang bin ich nicht davon ausgegangen, dass ein Feld, das durch
long int x[y];
im main-Bereich initialisiert wurde, auf dem stack landet.

marco

[A.K. (Gast)]

Ausserhalb Funktion: statische Adresse.
Innerhalb Funktion: auf dem Stack.
Anonsten siehe C Handbuch.