Timer Problem Mega64A

[Hans F. (hans_f83)]

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;
  }
}

[Rainer U. (r-u)]

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?

[S. Landolt (Gast)]

Hat dieses wirre Problem vielleicht etwas mit 'M103C' zu tun?

[Hans F. (hans_f83)]

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.

[Stefan F. (Gast)]

Hast du vor dem Debuggen eventuell vergessen, den Optimizer zu 
deaktivieren (Compiler Option -O0)?

[Hans F. (hans_f83)]

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

[S. Landolt (Gast)]

Der Stackpointer wird auf $10FF initialisiert, diese Adresse liegt beim 
103-Modus aber im external SRAM.

[S. Landolt (Gast)]

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.

[Hans F. (hans_f83)]

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.

[S. Landolt (Gast)]

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

[Hans F. (hans_f83)]

Danke nochmal Landold. Gespeichert und akzeptiert.
PS: um 18:45 war ich zu Tisch :) Ein leerer Magen denkt schlecht.