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?
Gast
#235243
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
Gast
#235244
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?
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
Gast
#235246
"weil offensichtlich der stackpointer zerschossen wird." Wodurch ist das "offensichtlich"?
Hallo, das sehe ich im disassambler-Fenster. Da springt der pc nach einer subroutine ins Nirgendwo. marco
Gast
#235248
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.
Gast
#235249
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
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
Gast
#235251
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.
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
Gast
#235253
Ausserhalb Funktion: statische Adresse. Innerhalb Funktion: auf dem Stack. Anonsten siehe C Handbuch.