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?
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.
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?
Ä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
"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.
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.
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.
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
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.
Simulator geht leider nicht gescheit durch das Bedienmenü. Tastaturinterrupt mit Ausleseroutine, automatische Statusregister für derzeitige Position im Menü und Display usw...
ich meinte einen Harken, nen kästechn zum ankreutzen, sorry. so finden in avrstudio unter project/Avr assembler setup/wrap relative jumps
nochmal sorry, ich versuche das nächste mal noch mehr tipfehler reinzubringen, ok?! :)
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 !
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.