|
Anzeige
|
Atmega32: Fehlerhafter Rücksprung aus ISRHallo, folgendes Problem: Atmega32. Nach Beendigung untenstehender ISR springt der Prozessor nicht in die Hauptschleife zurück sondern startet das Programm neu (Von Reset will ich erstmal nicht sprechen, da ich mir nicht sicher bin, ob ein solcher vollstädndig ausgeführt wird.)
Worann kann´s liegen? Lasst mich wissen, welche Infos ihr noch benötigt. Dank im Voraus, Harald Hallo Harald,
zwei Dinge:
*Signal ist veraltete Schreibweise; lade GCC neu dann nennst Du das
ganze: ISR {...}
* in einer ISR Interrupts zu erlauben ist etwas komisch. Mach das von
Deinem Hauptprogramm aus.
Gruß
Helmut
Helmut Ru wrote: > * in einer ISR Interrupts zu erlauben ist etwas komisch. Mach das von > Deinem Hauptprogramm aus. Das macht er ja gar nicht (zumindest nicht direkt). @Harald: Das cli() und sei() haben im Interrupt Handler nichts verloren! Das Sperren und Wiederfreigeben der Interrupt-Bearbeitung während der Abarbeitung des Interrupt-Handlers macht die Controller-Hardware automatisch. Zusätzlich selber machen kann in bestimmten Fällen nicht nur überflüssig, sondern fehlerträchtig sein Harald Horn wrote: > Atmega32. Nach Beendigung untenstehender ISR springt der Prozessor nicht > in die Hauptschleife zurück sondern startet das Programm neu (Von Reset > will ich erstmal nicht sprechen, da ich mir nicht sicher bin, ob ein > solcher vollstädndig ausgeführt wird.) Tja, hast Du eventuell dem Compiler nicht den richtigen Controllertyp angegeben? Der muss im Makefile entsprechend eingestellt sein. Und wirf mal einen Blick ins AVR-GCC-Tutorial.
Gast
#1213524
Ein Neustart des Programm unter avr-gcc liegt meistens an einem Interrupt, für den es keine ISR gibt. Da ist geht es dann als default über bad_interrupt auf den resetvektor. Welche Interrups hast du denn alle freigegeben? Und schmeiß das sei() und cli() aus der ISR. Das braucht es dort nicht, das macht die Hardware automatisch. Das sei() ist sogar gefährlich, denn an der Stelle ist die ISR noch (lange) nicht zu Ende. Oliver
Gast
#1213540
Vielleicht ist Dir mit Deiner Interrupt-Bastelei auch nur schlicht und ergreifend der Stack übergelaufen. Dann kann alles mögliche passieren (1+1=17; 1+1>1000) oder natürlich auch ein Reset.
Gast
#1213548
Es ist etwas unsinig, da der AVR aus der ISR raus sowieso keinen weiteren Interrupt ausführt. cli und sei kann also entfallen. Sollte aber nicht der Grund sein, oder... Je nachdem, wie schnell die Compare-Interrupts kommen, kann es durchaus sein, dass er sich durch das sei() am Ende ins Knie geschossen hat. Wenn zum Zeitpunkt des sei() schon der nächste Compare-Interrupt ansteht, kommt er aus dem Handler nicht wieder raus. Dann ist ein Stack-Überlauf beschlossene Sache. Von einem Stacküberlauf würde ich bei nur 4 Befehlen innerhalb der ISR nicht ausgehen. Dann wohl eher von einem fehlerhaft aktivierten Interrupt. Da uns der OP aber nicht mehr als das Schnipsel zeigen will, wird der Reset sein Geheimnis bleiben. Anmerkung: "cli()" und "sei()" sind Überbleibsel von einem Versuch, das Problem zu lösen; der Fehler trat auch vorher schon genau so auf. Gruß, Harald Harald Horn wrote: > Hallo, > > folgendes Problem: > > Atmega32. Nach Beendigung untenstehender ISR springt der Prozessor nicht > in die Hauptschleife zurück sondern startet das Programm neu (Von Reset > will ich erstmal nicht sprechen, da ich mir nicht sicher bin, ob ein > solcher vollstädndig ausgeführt wird.) Hallo, mal so ein Verdacht: im Simulator oder auf der realen Hardware ? Der simulator verblüfft manchmal, weil ganze Statements übersprungen werden. Da hilftt das Step-Through im Disassembler- Modus Gruß, Michael Hallo Oliver, > Ein Neustart des Programm unter avr-gcc liegt meistens an einem > Interrupt, für den es keine ISR gibt. Da ist geht es dann als default > über bad_interrupt auf den resetvektor. Welche Interrups hast du denn > alle freigegeben? bingo, das war´s. Da war von einem früheren Versuch noch ein externer Interrupt aktiviert. Jetzt geht´s! Danke! :-) Gruß, Harald Antwort schreiben |
Anzeige
|
