Forum: Mikrocontroller und Digitale Elektronik Atmega16 stürzt ab?


von Christian Kernstock (Gast)


Angehängte Dateien:

Lesenswert?

Hallo!

Hab da ein etwas umfangreicheres Programm für ein Netzgerät
geschrieben. Das Programm verwendet einige float
Multiplikationen/Divisionen und float-sprintf.  Nun beginnt der
ATmega16 "abzustürzen", wenn ich etwas hinzufüge... Wenn ich
"unwichtigen" bereits funktionsfähigen Code auskommentiere
funktioniert er wieder.  Kann es sein das der (RAM?)Speicher zu wenig
wird? Sprich der Stack irgendwas überschreibt? Wie kann ich das
kontrollieren?
Der avr-gcc sagt (für mich noch unverständliches):

Size after:
main.elf  :
section            size      addr
.text             11248         0
.data               688   8388704
.bss                149   8389392
.noinit               0   8389541
.eeprom               0   8454144
.stab               876         0
.stabstr            132         0
.debug_aranges       20         0
.debug_pubnames     680         0
.debug_info        2368         0
.debug_abbrev       614         0
.debug_line        2233         0
.debug_str         1012         0
.debug_ranges        24     11248
Total             20044

Bin für jede Hilfe dankbar
Christian

von Thomas O. (Gast)


Lesenswert?

könntest in die letzte SRAM Stelle nen bestimmten Wert reinschreiben
wenn der sich ändern weißt du das du nen Stacküberlauf hast.

von MasterFX (Gast)


Lesenswert?

Das deutet eigentlich darauf hin, das der Flash-Speicher zu klein ist.
Guck dir mal die Adressen im Hex-File an und guck ob die noch im
gültigen Bereich liegen.

von Christian Kernstock (Gast)


Lesenswert?

Danke euch beiden für die Antworten.

Variable beobachten ist eine gute Idee,  leider hab ich aber keinen
JTag...
Hab mir mal das ganze in AVRStudio angeschaut: der Disasembler  zeigt
mir als letzte beschriebene Stelle die 0x178F also es sollten noch ca.
10kByte frei sein.

mfg
Christian

von MasterFX (Gast)


Lesenswert?

Öhm sind das nicht 16Bit Adressen? Dann sollten das eher 12KB sein, das
würde sich dann mit
.text   11248     0
auch decken.

von Hans (Gast)


Lesenswert?

.data und .bss sind im ram

du hast also nur 187 bytes für heap und stack!!! zu 99,99% liegt hier
das problem... irgendwann wird der stack überschrieben und schon
landest du bei einem ret im nirvana...

fall der flash zu klein ist meldet sich normal der compiler und sagt
das...

73

von Jan M. (mueschel)


Lesenswert?

Ich schließe mich Hans an. Dafür gleich noch ein Lösungstipp: Verwende
statt printf() printf_P().
printf() kann nur Variablen aus dem Ram ausgeben, und diese werden
schon bei Programmstart in den Ram geladen.
printf_P() hingegen liest den auszugebenden Text direkt aus dem Flash.

von Dennis Kleine-Beck (Gast)


Lesenswert?

Hallo,

> du hast also nur 187 bytes für heap und stack!!!

Was für eine Mindestgröße für Heap + Stack ist denn empfehlenswert?
So als Richtwert, "über'n Daumen"

Dennis

von Jan M. (mueschel)


Lesenswert?

Das kommt auf das Programm an. Hast du ein Programm, das vollständig
linear abläuft, und nur globale Variablen verwendet, brauchst du
praktisch keinen Stack.
Pro Funktionsaufruf werden mindestens 2 Byte für die Rücksprungadresse
fällig, dazu noch < 20 Byte um Register zu sichern und der Speicher für
die lokalen Variablen in der Funktion. Wenn du viele Variablen an die
Funktion übergibst, landen die auch (ab 10 byte (?)) dort...
Wieviel Speicher du nun wirklich brauchst, hängt von vielen Faktoren
ab, vor allem auch von der möglichen Schachtelungstiefe der Funktionen
(a() ruft b() auf, ruft c() auf...)

von Christian Kernstock (Gast)


Lesenswert?

printf_P() ist meine neue Lieblingsfunktion geworden :-) brauch jetzt
statt 600Byte nur 40 Byte in der .data section. Und somit rennt der uC
auch wieder stabil.

Vielen Dank an Alle
Christian

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.