Atmega32: Fehlerhafter Rücksprung aus ISR

OP #1213509
Lesenswert?
• ▲
▼
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.)

1
SIGNAL (SIG_OUTPUT_COMPARE1B)
2
{
3
cli();
4
//Zündung
5
  PORTD |= (1<<PD2);
6
  PORTD &= ~(1<<PD2);
7
sei();
8
}

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

Dank im Voraus,
Harald
#1213522
Lesenswert?
• ▲
▼
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
#1213523
Lesenswert?
• ▲
▼
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
Lesenswert?
• ▲
▼
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
Lesenswert?
• ▲
▼
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.
#1213573
Lesenswert?
• ▲
▼
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.
#1213637
Lesenswert?
• ▲
▼
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
OP #1213714
Lesenswert?
• ▲
▼
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

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren