mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Grenze erreicht ?


Autor: Sirko Pöhlmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Poe (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Poe (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Henning (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: andré (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Poe (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Poe (Gast)
Datum:

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

Autor: Henning (Gast)
Datum:

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

Autor: Henning (Gast)
Datum:

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

Autor: Poe (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 !

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.