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:
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);
> 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?
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?
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...
> 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.
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.
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.
>> 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?
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!