AVR resetet von selbst

"Dschen Reinecke" schrieb im Newsbeitrag news: snipped-for-privacy@dschen.de...

Ist es bereits (in den Headerfiles).

Unerwartete ,,Resets'' sind übrigens fast immer ein Zeichen einer fehlenden Interruptbehandlung: der default handler macht schlicht einen JMP 0.

Ansonsten ist eventuell das GCC-Forum von avrfreaks der bessere Platz zum Fragen gerade für derartige Anfängerfragen. Dort gibt's meiner Meinung nach mehr Leute, die da helfen können als hier (weil gerade AVR-GCC-Anfänger hier eher selten sind).

Stümmt auffällig. Aber der Tipp mit volatile ist schön generisch. Meist hat man dann doch irgendwo vergessen, etwas volatile zu deklarieren und sucht vezweifelt. Schlicht ohne Optimierung zu übersetzen ist ein schneller Test, ob der Fehler da zusuchen ist. Falls das Kompilat dann och in den Prozessor passt ;-)

Naja, die disassemblierte Ausgabe zu nehmen und nachzusehen, was denn nun wirklich passiert ist oft der schnellere Weg. Sobald man sieht, wie es interpretiert wird stösst man schnell auf den dummen Tippfehler oder den nicht beachteten Vorrang der Operatoren. Und eine falsch gesetzte Klammer entzieht sich ja auch beim 25ten draufsehen hartnäckig dem Blick! :-(

un

Wie komme ich daran? Bei der fl=FCchtigen Suche sieht es so aus, als ob=20 mir mein Make-File keins erzeugt...

er m=FCsste

hnlich

Warum nicht gleich den generierten Assemblercode ansehen? avr-gcc -S Ich finde das meist übersichtlicher.

Disassemblieren läßt sich mit avr-objdump -d.

,=20

und=20

Den Fehler habe ich gefunden: Um Rechenzeit zu sparen erstelle ich mir an Anfang ein Array welches ich =

mit Rechenergebnissen f=FClle, dann mu=DF ich zur Laufzeit diese nicht=20 berechnen. Leider ist dieses mit 210 Chars recht gro=DF und ich habe noch= =20 ein paar andere Variablen...

Wenn ich jetzt auf ein Element zugreife, da=DF scheinbar nicht mehr in da= s=20 RAM passt, resetet sich der =B5C. Erstaunlicherweise nicht beim F=FCllen,= =20 sondern erst beim sp=E4teren Zugriff. Vielleicht wurde es beim=20 Funktionsaufruf vom Stack =FCberschrieben?

Ciao Dschen

--=20 Dschen Reinecke

=3D=3D=3D der mit dem Namen aus China =3D=3D=3D

das=20

n,=20

Wenn der Stack =FCberl=E4uft (oder wenn er gar nicht gesetzt wurde), dann=

gibts auch einen Reset.

Markus

Das ist zumindest atypisch. Der Stack ist als Ringpuffer implementiert, dessen Zeiger beim Ablegen von Daten dekrementiert wird. Also würde ein Überlauf des Stacks doch nur darin bestehen, daß abgelegte Daten überschrieben werden, was dann zu Laufzeitfehlern führt. Wenn ein Übergang des Stackpointers von $0000 nach $ffff zu einem Reset führt, liegt meines Erachtens ein Fehler in der Hardware vor. Einen Interrupt könnte ich mir noch vorstellen, aber gleich ein Reset?

Holger

Es gibt zwar keinen echten Reset aber: Wenn Du Deine Rücksprungadresse auf den Stack legst der gar nicht mehr pysikalisch im RAM liegt dann landest Du bei einem Rücksprung auf 0xffff (rcall/ret irq usw), unterstes Bit wird nicht ausgewertet, die höheren auch nicht, weil der Program Counter ggf. nur so groß ist wie das Flash. Und wenn nicht gerade ein Sprung auskodiert wird (keine Ahnung was

Gruß Klaus