Forum: Mikrocontroller und Digitale Elektronik Grenze erreicht ?


von Sirko Pöhlmann (Gast)


Lesenswert?

Hallo!

ich hab hier ein Programm (ach was?). Das Ganze ist über 5 Dateien
verteilt, beinhaltet 2960 Wörter Code, 145 Konstanten und ist ergo 3105
Wörter groß.

Das hex liegt so bei 18kb.

Ich bin jetzt an einem Punkt wo jeglicher zusätzlicher Befehl im Code
zu einem reproduzierbaren Fehler im Programmablauf führt. Also auch nur
wenn ich irgendwo im Code ein nop reinschreibe. Es ist wie gesagt völlig
egal welcher Befehl und wo im code der steht.

Programmierung ist Assambler, Mc ist ein mega32, benutzt wird AVRStudio
4.07.

Ich bekomme keinerlei Fehlermeldung.
Ich habe überlegt ob der Stack von hinten her vollläuft und mit dem
Speicher kollidiert. Deshalb hab ich mal das RAMEND etwas verleinert in
der Annahme das dann das Problem erst recht auftreten sollte. Das ist
aber nicht der Fall.
Ich bin mit dem alten AVR Studio mal an Editorgrenzen gestoßen, aber
das ist ja nun nicht mehr...das ich irgendwelche Befehlssprungweiten
überschreite ist auch nicht.. für sowas gibts ja Fehlermeldungen...

wer kennt das Problem, hat eine Vermutung oder kann mir sonst irgendwie
helfen?

von Ronny Schulz (Gast)


Lesenswert?

Wenn Du viel rekursiv verzweigst oder andere Sachen machst, die den
Stack belasten, dann kann der schon überlaufen. Auch kann natürlich zu
viel im RAM gespeichert sein.

Im Prinzip kann irgendwo ein ganz kleiner Fehler sein, wo eine kleine
Änderung am Code einen vollen Absturz bedeutet. Ich hatte das anfangs
auch mal. War ein Stack-Problem.

von Poe (Gast)


Lesenswert?

Im Prinzip kann irgendwo ein ganz kleiner Fehler sein, wo eine kleine
Änderung am Code einen vollen Absturz bedeutet. Ich hatte das anfangs
auch mal. War ein Stack-Problem.

Auch wenn es ausreicht IRGENDWO im Code, und sei es in der ersten
Zeile,  ein nop zu schreiben um den Fehler auszulösen?

Ich kann ja nun nicht das kanze Programm kippen nur weil der Stack
überläuft oder so ( wenn es daran liegt !) Ist der den begrenzt? Ich
dachte der ist insoweit "unendlich" bis er mit dem Code kollidiert.
Daher ja auch mein Test mit verändertem RAMEND.

Wenn es am Stack liegt, sollte das Problem dann nicht nur dann
entstehen wenn ich ein rcall oder sowas aufrufe? Ein nop an einer
beliebigen Codestelle beeinflußt doch den Stack nicht zwingend oder?

Ich meine, der Stack war ja auch mein Problemkandidat, aber mit dem
Verhalten?

von Peter D. (peda)


Lesenswert?

Ältere AVR Assembler haben die Adreßberechnung bei Konstanten falsch
gemacht.

Dann reicht ein NOP mitten im Code aus, um völlig was anderes zu
machen.

Der Fehler trat aber nur auf, wenn in den .DB-Anweisunge eine ungerade
Anzahl von Bytes war.


Peter

von Tobias (Gast)


Lesenswert?

"Ich dachte der ist insoweit "unendlich" bis er mit dem Code
kollidiert."

Die Avrs haben eine Havard-Architktur, d.h. Programm- und
Arbeitsspeicher (Ram) sind voneinander physikalisch getrennt. Es ist
hier nicht wie bei einem PC, wo das Programm aus nichtflüchtigem
Speicher ins Ram geladen wird und sich in dem selben Ram auch noch die
Variablen und der Stack befinden. Bei den Avrs wird der Code direkt aus
dem Flash gelesen, ebenso wie die Konstanten. Falls du Variablen hast,
werden diese, genau wie der Stack, ins Ram geschrieben und von dort
auch ausgelesen. Es kann also passieren, das du mit dem Schreiben einer
Variablen den Stack zerstörst oder umgekehrt, nicht aber den
Programmcode. Den kann nur ein Bootloader zerstören.

@Sirko Pöhlmann:
"das ich irgendwelche Befehlssprungweiten überschreite ist auch
nicht.. für sowas gibts ja Fehlermeldungen... "
Ich kann dir sagen, das es die bei MPLAB 6.30 noch nicht gab.
Wie es heute ist weiss ich nicht, arbeite nicht mehr mit Pics. Ich
hoffe das du Recht hast und die Atmel Leute schlauer waren. Aber als so
sicher würde ich das nicht ansehen.

T.

von Poe (Gast)


Lesenswert?

ah ja das mit dem Flash und Ram haue ich immer mal durcheinander und
merke es mir nicht, danke.

die Fehlermeldungen gibt es wirklich, bei Programmverzweigungen hatte
ich es schon....

es ist übrigens so das wenn ich irgendwo Programmcode gelöscht wird (
zB wait- Routinen die nicht gebraucht werden) ich wieder "Platz" für
weiteren Code gewinne, es scheint als Volumenbedingt.

Da sich der Stack ja aber nur mit den vereinbarten Variablen den RAM
teilt verstehe ich nicht wie der als Problemverursacher da reinpasst.

von Henning (Gast)


Lesenswert?

es gibt einen kacken in den optionen wrap jumps oder so

und sonnst heißt es wohl push und pop zählen und aupassen das nirgendwo
jmp mit ret beendet wird.
hab mein projekt neu aufgebaut, aber die programmteile dabei immer
übernommen, genaustens angeguckt - und den fehler gefunden.

von andré (Gast)


Lesenswert?

Kannst den Code nicht einfach mal in nem Simulator laufen lassen und da
den Fehler suchen? Geht evtl einfacher als Raetselraten :). Weiss nicht
wie das in AVRstudio so ist, arbeite damit nicht. Bedingt durch die
Groesse koennte das mit dem simulieren aber auch etwas laenger
dauern...

mfg

von Poe (Gast)


Lesenswert?

es gibt einen kacken in den optionen wrap jumps oder so

HÄ??

und sonnst heißt es wohl push und pop zählen und aupassen das
nirgendwo
jmp mit ret beendet wird.

Ehrlich gesagt hab ich außer bei den Interrupts kein push und pop, ich
speichere relativ oft die Variablen statt sie zu pushen.

das beenden eines jmp mit ret würde zu einem Stacküberlauf führen. Das
ist ziemlich ausgeschlossen ( naja, soweit ich das beurteilen kann) da
es ja unabhängig von der Codegröße auftreten würde.

Das Program ist ein Bedienmenü (4Rasten, LCD; RTC; EEPROM). Ich kann -
wenn ich im "Volumenrahmen" bleibe beliebig lange und oft durch das
Menü zappen, sobald das "Volumen" überschritten ist (zb nop) ist beim
dritten Hauptmenüpunkt Schluß und  das Programm resetet. Wenn ich den
Code noch weiter erhöhe komme ich nur noch zum zweiten Menüpunkt usw.


Hm. ich check das trotzdem nochmal mit den ret, aber ist durch die
Schachtelung verdamt schwierig. Mist das sich zu einem rcall der
rückbefehl nicht farblich hervorheben läßt...

hab mein projekt neu aufgebaut, aber die programmteile dabei immer
übernommen, genaustens angeguckt - und den fehler gefunden.

von Poe (Gast)


Lesenswert?

Simulator geht leider nicht gescheit durch das Bedienmenü.
Tastaturinterrupt mit Ausleseroutine, automatische Statusregister für
derzeitige Position im Menü und Display usw...

von Henning (Gast)


Lesenswert?

ich meinte einen Harken, nen kästechn zum ankreutzen, sorry. so finden
in avrstudio unter project/Avr assembler setup/wrap relative jumps

von Henning (Gast)


Lesenswert?

nochmal sorry, ich versuche das nächste mal noch mehr tipfehler
reinzubringen, ok?! :)

von Poe (Gast)


Lesenswert?

AHH, Haken (?), wie das Ding wo man den Mantel dranhängt, :-), ok.
Ich seh mal zu. Hab aber gerade auch ein rcall gefunden wo ein rjmp
hinsollte , gott sei dank schon in der 2 Schachtelebene.... mal sehen
obs nun besser ist.

Danke für die fixen Antworten hier !

von Heinz (Gast)


Lesenswert?

Dann such mal weiter, du hast den Code, also können wir nicht mit
suchen, musst du schon selbst machen. Aber einer dieser
RCALL/RJMP-Verwechsler reicht für Stackfehler aus.
Übrigens überschreibt ein überlaufender Stack nach den (SRAM-)Variablen
den I/O-Bereich und dann die Register.

Bau doch mal eine Debug-Routine ein, die dir den Inhalt des
Stackpointers auf dem LCD anzeigt, dann siehst du mehr.

MfG, Heinz

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.