ATtiny26 - timer0 interrupt führt zu Reset

[Jens S. (darkridge)]

Hallo, ich bin neu im Forum, habe aber schon etwas Erfahrung mit uC's.

Für eine Timer-Anwendung brauche ich einen Timer Interrupt vom ATtiny26 
und verwende hierfür Timer/Counter0 (mit Timer/Counter1 habe ich das 
gleiche Problem).

Sobald ich den Interrupt enable (sei() und TCCR0) führt der uC endlos 
Resets durch.

Das Verhalten ist gleich, auch wenn die ISR gar nicht definiert ist.

Das Verhalten ist gleich bei interner Clock und Crystal Oscillator.

Durch "LED-Debugging" habe ich herausgefunden, dass der Zähler TCNT0 
funktioniert, und dass der Interrupt Flag TOV0 gesetzt wird.

Ich vermute, dass der Interrupt ausgelöst wird aber anstatt zur ISR zum 
Reset Vektor springt.

Ich kompiliere und programmiere mit:

$ avr-gcc -I. -O6 -g -mmcu=attiny26 -Wcpp -o $@ $<
$ avrdude -p t26 ...

Fällt jemandem hier was auf?

#define F_CPU (1600000L)


#include<avr/io.h>
#include<avr/interrupt.h>
#include<util/delay.h>


ISR( TIMER0_OVF0_vect ) {
  PORTA &= ~(1<<7);
}

void greeting () {
  uint8_t i, ii;
  for (ii=0; ii<2; ii++ ) {
    for ( i=0; i<10; i++ ) {
      PORTA ^= (1<<(0+ii));
      _delay_ms(40);
    }
  }
}

main()
{

  DDRA=0xFF;
  PORTA=0xFF;

  TIMSK = (1<<TOIE0);
  TCNT0 = 0;
  greeting();

  TIFR &= ~(1<<TOV0);
  TIFR &= ~(1<<TOV1);
  sei();
  TCCR0 = 5;

  while(1) {}
}

[MWS (Gast)]

Jens Schäfer schrieb:
> Ich vermute, dass der Interrupt ausgelöst wird aber anstatt zur ISR zum
> Reset Vektor springt.

Das passiert nur, wenn der angegebene Interruptname dem Compiler nicht 
bekannt ist, dann wird auf Reset umgelenkt. Sieht aber nicht so aus, die 
iotn26.h kennt den TIMER0_OVF0_vect.

Du könntest das erzeugte .hex anhängen, dann kann man nachschauen, was 
passsiert.

Übrigens, so löscht man keine Flags:

Jens Schäfer schrieb:
> TIFR &= ~(1<<TOV0);
> TIFR &= ~(1<<TOV1);

[Jens S. (darkridge)]

> Du könntest das erzeugte .hex anhängen, dann kann man nachschauen, was
> passsiert.

Vielen Dank! Anbei das HEX-File.

> Übrigens, so löscht man keine Flags:

Ja, stimmt. - Das hatte ich vor Verzweiflung mal reingeschrieben. Für 
das aktuelle HEX-File habe ich es wieder rausgenommen. (Keine Änderung 
im Verhalten.)

Übrigens kommt der Reset tatsächlich erst, wenn TCNT0 überläuft, also 
der Interrupt Flag gesetzt wird.

Blöde Frage: Wie analysierst Du denn  das HEX-File?

[Marc V. (Firma: Vescomp) (logarithmus)]

Jens Schäfer schrieb:
> Übrigens kommt der Reset tatsächlich erst, wenn TCNT0 überläuft, also
> der Interrupt Flag gesetzt wird.

  TIFR &= ~(1<<TOV0);
  TIFR &= ~(1<<TOV1);

 Wie wäre es, wenn du diese 2 Zeilen mal rauswirfst ?
 Oder zumindest die untere ?

[Route_66 H. (route_66)]

Jens Schäfer schrieb:
> Ja, stimmt. - Das hatte ich vor Verzweiflung mal reingeschrieben. Für
> das aktuelle HEX-File habe ich es wieder rausgenommen. (Keine Änderung
> im Verhalten.)

Marc, nicht gelesen?

[H.Joachim S. (crazyhorse)]

Jens Schäfer schrieb:
> Blöde Frage: Wie analysierst Du denn  das HEX-File?

Das kann man sich auch ins AVR-Studio laden :-)

[Marc V. (Firma: Vescomp) (logarithmus)]

Route 66 schrieb:
> Marc, nicht gelesen?

 Ooops.
 Gelesen schon, aber übersehen, sorry.
 Aber das ist auch die einzige Stelle im Programm, wo er wieder zum
 Reset springen kann, da ja TCNT1-ISR nicht definiert ist...

[Bernhard F. (bernhard_fr)]

Dann bleibt ja nicht mehr viel übrig...

Ist denn

ISR( TIMER0_OVF0_vect )

richtig?

Kannst du mal stattdessen

ISR(_VECTOR(6))

probieren?

[Karl H. (kbuchegg)]

Bernhard F. schrieb:
> Dann bleibt ja nicht mehr viel übrig...
>
> Ist denn
>

> ISR( TIMER0_OVF0_vect )
>

> richtig?

Scheint richtig zu sein, solange der richtige µC in der IDE eingestellt 
ist.

> Kannst du mal stattdessen
>

> ISR(_VECTOR(6))
>

> probieren?

Keine gute Idee.

[Jens S. (darkridge)]

> Kannst du mal stattdessen
> ISR(_VECTOR(6))

Habe ich gemacht. - Keine Besserung.

(Die Definition in der iotn26.h hatte ich zuvor schon geprüft.)

[Jens S. (darkridge)]

> Scheint richtig zu sein, solange der richtige µC in der IDE eingestellt
> ist.

Ich programmiere von der Kommandozeile. Deshalb hatte ich oben den 
avr-gcc-Befehl mit angegeben.

[Stefan E. (sternst)]

Jens Schäfer schrieb:
> Ich kompiliere und programmiere mit:
> $ avr-gcc -I. -O6 -g -mmcu=attiny26 -Wcpp -o $@ $<
> $ avrdude -p t26 ...

Kein Wunder, dass Interrupts nicht funktionieren, wenn du das ELF-File 
in den Controller lädst.

Jens Schäfer schrieb:
> Anbei das HEX-File.

Nö. Dem ELF-File eine andere Endung zu verpassen, macht daraus kein 
HEX-File.

[MWS (Gast)]

Jens Schäfer schrieb:
> Vielen Dank! Anbei das HEX-File.

War kein Intel-Hex, statt dessen ein ELF, laden und simulieren konnte 
man's im AVR-Studio.

Der OVF0 löst aus wie er soll und springt auch nirgends anders hin, als 
in die ISR.

Such' mal im Codeordner nach dem Intel-Hex und flash dieses.

[Jens S. (darkridge)]

Strike! - Das war's!

Ich habe in der Tool-Chain glatt den avr-objcopy vergessen! - Da wäre 
ich nie drauf gekommen.

Vielen Dank! - Ihr seid super!

[Bernhard F. (bernhard_fr)]

Karl Heinz schrieb:
>> Kannst du mal stattdessen
>>

>> ISR(_VECTOR(6))
>>

>> probieren?
>
> Keine gute Idee.

AHHH... Kopf-> Tisch. Es wäre auch Vektor 7 an Adresse $006. Und mal 
wieder zeigt sich deutlich, warum Atmel dafür eindeutige 
Präprozessorkonstanten vorgesehen hat.

War es das? Oder kommt noch was dazu?

[Jens S. (darkridge)]

Das war's. Das Makefile macht jetzt folgendes:

  avr-gcc -> ELF-File -> avr-objcopy -> HEX-File -> uC

Der Fehler entstand durch:

  avr-gcc -> ELF-File -> uC

Das Gemeine war, dass mit dem ELF File alles Funktioniert hat, nur eben 
die ISR nicht.

Nochmals vielen Dank für Eure Hilfe!