Hallo zusammen, nach langer Abstinenz beschäftige ich mich zur Zeit wieder mit der Atmel Programmierung. Seit Stunden suche ich jetzt nach einem Problem und komme nicht weiter. Wenn ich in der Timer ISR den Counter verwende, wird die LED nie eingeschaltet. Ein Debug Punkt im IF Statement in der ISR wird nie erreicht. Setze ich im MAIN einen Breakpunkt auf der Freischaltung der IRQ, wird dieser zyklisch erreicht, so als würde die CPU beim Zugriff auf die Counter Variable booten. Steppe ich die ISR im Einzelschritt, funktionierts. Kommentiere ich das IF Statement mit dem Counter aus, funktionierts auch und die LED blinkt. Der Breakpunkt im Main wird dann nur noch beim Programmstart erreicht, so wie es halt auch soll. Die Hardware ist eine Eigenentwicklung. Debug Interface Atmel ICE (JTAG). Entweder ich mache hier einen ganz blöden Anfängerfehler, oder das Problem liegt ggf. im Hardware Design. Wobei, warum soll die Hardware zicken machen wenn ich eine Variable incrementiere? Komme nicht dahinter :( Hier das Programm (aktuelles Atmel Studio 7) #include <avr/io.h> #include <util/delay.h> #include <avr/interrupt.h> volatile int8_t mycounter = 0; int main(void) { DDRA |=(1<<PINA0); // Timer 0 konfigurieren TCCR0 = ((1<<CS02)|(1<<CS01)|(1<<CS00)); // Prescaler // Overflow Interrupt erlauben TIMSK |= (1<<TOIE0); sei(); while (1) { } } ISR (TIMER0_OVF_vect) { if(++mycounter == 10) { PORTA ^= (1 << PINA0); mycounter =0; } }
Hans F. schrieb: > Kommentiere ich das IF Statement mit dem Counter aus, funktionierts auch > und die LED blinkt. Und wenn Du es mal in 2 Zeilen schreibst? (hochzählen und vergleichen extra) - welches von beiden klappt? Nach wie viel Zeit soll die LED umschalten?
Gast
#5312287
Hat dieses wirre Problem vielleicht etwas mit 'M103C' zu tun?
Die CPU läuft mit einem externen Quarz (16Mhz). Für den Timer habe ich schon den größten Prescaler eingestellt. Die Blickfrequenz sollte variabel von ca. 1 - 100hz sein, darum der Counter. Den Counter in einer 2ten Zeile zu inkrementieren, habe ich auch schon versucht. Gleiches Ergebnis. Habe auch schon versucht mit dem internen Oscillator von 8Mhz zu arbeiten. Ändert nichts. Nach dem letzten Test sieht es jetzt so aus als würde der Compiler den Counter wegoptimieren. Optimierung ist aber aus. Zum Test habe ich mal hinter dem "IF" einen weiteren Ausgang geschaltet. Daran kann ich sehen, dass der Interrupt immer kommt.
Gast
#5312328
Hast du vor dem Debuggen eventuell vergessen, den Optimizer zu deaktivieren (Compiler Option -O0)?
So, Problem gelöst. S. Landolt hat mich drauf gebracht. In den Fuse Settings war die Extended.Compmode Fuse gesetzt. Was auch immer die Fuse bewirkt, Fuse gelöscht und schon funktionierts. Manchmal ist es gut, einfach drüber zu reden. Danke euch allen. Hans
Angehängte Dateien:
-
Fuse.JPG
(29 KB)
Gast
#5312420
Der Stackpointer wird auf $10FF initialisiert, diese Adresse liegt beim 103-Modus aber im external SRAM.
Gast
#5312442
Fasnet, ausnahmsweise sei eine leise Kritik gestattet: selbst wenn ich mit dem Landolt nichts zu tun habe möchte und deshalb nicht nachfrage, was mit 'M103C' gemeint ist, so hätte ich doch im Datenblatt nach diesem Begriff gesucht und wäre spätestens um 18:45 zur Lösung gelangt.
Danke für die Info. Ich habe mir das Kapitel im Manual gerade durchgelesen. Eine wirkliche Erklärung für das Verhalten leuchtet mir damit allerdings nicht ein. Bis auf: • Port F serves as digital input only in addition to analog input to the ADC. Hier liegt ja das JTAG Interface.
Gast
#5312469
Eine genaue Erklärung kann ich auch nicht bieten, aber wie gesagt zeigt
der Stackpointer ins Nichts, also sind Rücksprünge aus der ISR nicht
möglich, und das passt irgendwie zu
> als würde die CPU ... booten
Danke nochmal Landold. Gespeichert und akzeptiert. PS: um 18:45 war ich zu Tisch :) Ein leerer Magen denkt schlecht.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.