Atmega32: Fehlerhafter Rücksprung aus ISR

[Harald H. (harald_horn)]

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.)

SIGNAL (SIG_OUTPUT_COMPARE1B)
{
cli();
//Zündung
  PORTD |= (1<<PD2);
  PORTD &= ~(1<<PD2);
sei();
}

Worann kann´s  liegen?
Lasst mich wissen, welche Infos ihr noch benötigt.

Dank im Voraus,
Harald

[Helmut R. (heru01)]

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

[Johannes M. (johnny-m)]

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

[Johannes M. (johnny-m)]

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.

[Oliver (Gast)]

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

[nixVerstaan (Gast)]

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.

[Sven (Gast)]

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...

[Johannes M. (johnny-m)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Harald H. (harald_horn)]

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

[Michael A. (micha54)]

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

[Harald H. (harald_horn)]

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