Atmega16 stürzt ab?

Gast #348940
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
Angehängte Dateien:
Gast #348943
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
Gast #348945
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
#348946
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.
#348948
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...)
Gast #348949
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

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.