Timer1 Overflow interrupt löst nicht aus (AtMega32)

[Michael Z. (incunabulum)]

Moin,

ich glaub ich werd noch blöd (oder betriebsblind).... Jedenfalls
weigert sich bei mir Timer1 standhaft, die entsprechende ISR-Routine
aufzurufen.

Ergebnis ist, dass der Controller alle ca. 4. Sekunden resettet (LED an
PC7 wird geschaltet) und die main()-Routine wieder von neuem startet.
Bei einem CPU Takt von 16 Mhz und einem prescaler von 1024 entspricht
dies ziemlich genau der Überlaufzeit des Timers1.

Den reset erkläre ich mir damit, dass ein Interrupt nicht durch eine
Routine aufgefangen wird und dementsprechend der reset ausgelöst wird.
Nur wieso? Warum landet der Overflow interrupt von Timer1 nicht in
TIMER1_OVF_vect? Warum werden evtl. vorhandene weitere Interrupts nicht
in __vector_default gehandlet?

Kurz, ich hab keine Idee mehr, woran es liegen könnte.... was mach ich
da falsch? Danke, Michael

Entwicklungsumgebung: WinAvr mit avr-gcc 3.4.6, avr-lb 1.4.4, Eclipse

Dies ist mein Testcode:

#define F_CPU 16000000

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


ISR (TIMER1_OVF_vect) {
    PORTC ^= 1 << PC4;
}

ISR (__vector_default) {
  PORTC &= ~(1 << PC0);
}


void delay_ms(uint16_t delay) {
  uint16_t i;
  for (i = 0; i < delay; i++) {
    _delay_ms(1);
  }
}

void delay_sec(uint8_t delay) {
  uint8_t i;
  for (i = 0; i < delay; i++) {
    delay_ms(1000);
  }
}

int main (void)
{
    DDRC = 0xFF;      // Port Ausgang
  PORTC = 0xFF;      // Port Pullups

    PORTC &= ~(1 << 7);
    delay_sec(2);
    PORTC ^= 1 << PC7;


// timer stuff
  TCCR1B |= (1<<CS12)|(1<<CS10);
  // TCCR1B |= (1<<CTC1)|(1<<CS12)|(1<<CS10);
  TIMSK  |= (1<<TOIE1);
  sei();

    while(1) {
      delay_sec(1);
      PORTC ^= 1 << PC1;
    }
    return 1;
}

[Karl H. (kbuchegg)]

Schmeiss die avr/signal.g raus.
Die bringt den Compiler durcheinander.

Habs grade im Simulator probiert:
mit: kein Interrupt
Ohne: Interrupt kommt wunderbar

[Michael Z. (incunabulum)]

Moin Karl Heinz,

danke für die schnelle Antwort... die signal.h hatte ich nur drin, um
zu schauen, ob ein SIGNAL() etwas bringt. Tut es nicht.

Inzwischen bin ich etwas weiter. Es scheint, als ob bei den
Einstellungen für make und den linker etwas bei Eclipse bzw. beim
entsprechenden avrgcc plugin nicht stimmt.

Mit dem identischen Code oben habe ich es mit AvrStudio und Eclipse
getestet. Folgendes Ergebniss:
1) AvrStudio: klappt
2) Eclipse Managed C Project: Interrupts werden nicht ausgelöst, PC1
wird aber immerhin in main() ein uns ausgeschaltet
3) Eclipse Managed C++ Project:  Reset nach ca. 4 Sekunden; ergo wird
der interrupt ausgelöst aber nicht in der ISR()-Routine gecatcht.

Unten noch die entsprechenden Make-Anweisungen. Schade eigentlich, da
ich eclipse doch als IDE mag und auch einige C++ Klassen verwende
(FiFo, Ringbuffer etc.)

Nur hab ich hiervon gar keine Ahnung.....

cu, Michael


## Make Anweisungen ## Make Anweisungen ## Make Anweisungen ##

**** AvrStudio ****
avr-gcc.exe  -mmcu=atmega32 -Wall -gdwarf-2 -DF_CPU=16000UL -O0
-funsigned-char -MD -MP -MT avrTest.o -MF dep/avrTest.o.d  -c
../avrTest.c
avr-gcc.exe -mmcu=atmega32  avrTest.o     -o avrTest.elf
avr-objcopy -O ihex -R .eeprom  avrTest.elf avrTest.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section-lma .eeprom=0 -O ihex avrTest.elf avrTest.eep

**** Eclipse CPP ****
avr-g++ -c -fmessage-length=0 -Wall -mmcu=atmega32 -minit-stack=__stack
-O0 -fshort-enums -fpack-struct -funsigned-char -funsigned-bitfields
-std=gnu++98 -g2 -o"main.o" "../main.cpp" && \
echo -n 'main.d' ./ > 'main.d' && \
avr-g++ -c -MM -MG -P -w -fmessage-length=0 -Wall -mmcu=atmega32
-minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char
-funsigned-bitfields -std=gnu++98 -g2  "../main.cpp" >> 'main.d'
avr-g++ -o  "avrTest.elf"  ./main.o    -lm -Wl,-Map=avrTest.map
--cref --oformat=elf32-avr
avr-objcopy -j .text -j .data  -O ihex avrTest.elf avrTest.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section-lma .eeprom=0  -O ihex avrTest.elf avrTest.eep
avr-objdump  -h -S avrTest.elf >avrTest.lss

**** Eclipse C ****
avr-gcc -c -fmessage-length=0 -Wall -Wstrict-prototypes -mmcu=atmega32
-minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char
-funsigned-bitfields -std=gnu99 -g2 -o"main.o" "../main.c" && \
echo -n 'main.d' ./ > 'main.d' && \
avr-gcc -c -MM -MG -P -w -fmessage-length=0 -Wall -Wstrict-prototypes
-mmcu=atmega32 -minit-stack=__stack -O0 -fshort-enums -fpack-struct
-funsigned-char -funsigned-bitfields -std=gnu99 -g2  "../main.c" >>
'main.d'
avr-gcc -o  "avrTestC.elf"  ./main.o    -lm -Wl,-Map=avrTestC.map
--cref --oformat=elf32-avr
avr-objcopy -j .text -j .data  -O ihex avrTestC.elf avrTestC.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section-lma .eeprom=0  -O ihex avrTestC.elf avrTestC.eep
avr-objdump  -h -S avrTestC.elf >avrTestC.lss

[Jörg W. (dl8dtl) (Moderator)]

> Schmeiss die avr/signal.g raus.
> Die bringt den Compiler durcheinander.

Hmm, kann eigentlich nicht sein, dieser Header besteht ja nur
noch daraus:

#warning "This header file is obsolete.  Use <avr/interrupt.h>."
#include <avr/interrupt.h>

Da alle System-Headerdateien (außer <assert.h>) "idempotent" sind,
d.h. sich gegen Mehrfach-Includes schützen, sollte das zusätzliche
Include nichts ausmachen.

> 1) AvrStudio: klappt
> 2) Eclipse Managed C Project:

Deja vu.  Wann zum Geier wird dieses blöde Eclipse-Plugin endlich
mal repariert und übergibt beim Linken -mmcu= mit?  Das ist schon
so oft durchgekaut worden...

[Michael Z. (incunabulum)]

Sodele,

Wenn man nur lang genug auf den Code schaut und im Netz sucht, findet
man immer eine Lösung. Ob es klappt muss ich allerdings noch testen.

Zitat von hier:
http://www.mikrocontroller.net/forum/read-2-398809.html#399245

In dem Plugin ist ein Fehler.
Du musst beim Linker auch den Typ des Controllers angeben. Das kann man
nur beim Assembler und Compiler auswählen. Beim Linker hat PEter es wohl
übersehen. Versuch das einfach mal von Hand in den Aufruf des Linkers
einzugben.

Exakt hiermit hatte ich auch Probleme als ich ein Programm, das vorher
mit dem avr-gcc compiliert wurde und einwandfrei lief, mit Eclipse
compiliert hatte. Bis ich es dann im Wechsel compiliert hatte (erst
eclipse dann von hand). Da hatte ich den unterschiedlichen Aufruf
festgestellt.

[Karl H. (kbuchegg)]

> Hmm, kann eigentlich nicht sein, dieser Header besteht ja nur
> noch daraus:

Da muss ich irgendwo einen Fehler gemacht haben.
Jetzt krieg ichs nicht mehr hin. Mit und ohne geht.

Ich denke ich hab den Simulator mal verwirrt als ich einen
falschen Prozessor ausgewählt habe.