Atmega88pa - Absturz bei Timerinterrupt

[Cyclon (Gast)]

Moin,
ich habe hier ein kleines Problem mit meinem mega88pa.
In meinem Programm nutze ich alle 3 Timer. Doch egal bei welchem und 
egal ob Timer-Overflow oder Output-Compare, jedesmal wenn ein Interrupt 
ausgelöst werden soll, startet der µC neu. Allerdings nur bei 
Timer-Interrupts. Daher befürchte ich, habe ich dort nen Denkfehler 
drinnen.
Ich hab meinen Code schon auf ein Minimum reduziert, um evtl. 
Fehlerquellen auszuschließen. Vielleicht mag sich das einer von euch mal 
ansehen:

#include <avr/io.h>
#include <avr/interrupt.h>
#include "uart.h"


ISR(TIMER2_OVF_vect) {
  TCCR2B = 0;
  sendData(1,1,1,0,0);
}

int main(void) {
  initUart(0);
  sei();
  sendData(0,0,0,0,0);

  TIMSK2 = (1<<TOIE2);
  TCCR2B = (1<<CS22) | (1<<CS20);
  while(1) {
  }
  return 0;
}

sendData überträgt mir Daten über nen RS485-Bus an den PC. Die Funktion 
arbeitet einwandfrei und kann als Fehlerquelle ausgeschlossen werden, 
daher habe ich sie nicht extra mit aufgeführt. Wenn ich den Timer 
deaktiviert lasse, werden die Daten des nach sei() kommenden sendData 
genau einmal übertragen, wie erwartet.
Stelle ich jedoch den Timer so ein, das er ein Interrupt generiert, 
bekomme ich die Daten im Takt des Interrupts. Das sendData in der ISR 
hingegen wird nie erreicht. Folglich wird die ISR nie ausgeführt und der 
µC resettet sich ständig.

Die Interrupt-Vektortabelle sieht für mich auch ok aus:

00001800 <__vectors>:
    1800:  19 c0         rjmp  .+50       ; 0x1834 <__ctors_end>
    1802:  28 c0         rjmp  .+80       ; 0x1854 <__bad_interrupt>
    1804:  27 c0         rjmp  .+78       ; 0x1854 <__bad_interrupt>
    1806:  26 c0         rjmp  .+76       ; 0x1854 <__bad_interrupt>
    1808:  25 c0         rjmp  .+74       ; 0x1854 <__bad_interrupt>
    180a:  24 c0         rjmp  .+72       ; 0x1854 <__bad_interrupt>
    180c:  23 c0         rjmp  .+70       ; 0x1854 <__bad_interrupt>
    180e:  22 c0         rjmp  .+68       ; 0x1854 <__bad_interrupt>
    1810:  21 c0         rjmp  .+66       ; 0x1854 <__bad_interrupt>
    1812:  35 c0         rjmp  .+106      ; 0x187e <__vector_9>
    1814:  1f c0         rjmp  .+62       ; 0x1854 <__bad_interrupt>
    1816:  1e c0         rjmp  .+60       ; 0x1854 <__bad_interrupt>
    1818:  1d c0         rjmp  .+58       ; 0x1854 <__bad_interrupt>
    181a:  1c c0         rjmp  .+56       ; 0x1854 <__bad_interrupt>
    181c:  1b c0         rjmp  .+54       ; 0x1854 <__bad_interrupt>
    181e:  1a c0         rjmp  .+52       ; 0x1854 <__bad_interrupt>
    1820:  19 c0         rjmp  .+50       ; 0x1854 <__bad_interrupt>
    1822:  18 c0         rjmp  .+48       ; 0x1854 <__bad_interrupt>
    1824:  17 c0         rjmp  .+46       ; 0x1854 <__bad_interrupt>
    1826:  16 c0         rjmp  .+44       ; 0x1854 <__bad_interrupt>
    1828:  15 c0         rjmp  .+42       ; 0x1854 <__bad_interrupt>
    182a:  14 c0         rjmp  .+40       ; 0x1854 <__bad_interrupt>
    182c:  13 c0         rjmp  .+38       ; 0x1854 <__bad_interrupt>
    182e:  12 c0         rjmp  .+36       ; 0x1854 <__bad_interrupt>
    1830:  11 c0         rjmp  .+34       ; 0x1854 <__bad_interrupt>
    1832:  10 c0         rjmp  .+32       ; 0x1854 <__bad_interrupt>

Hat jemand ne Idee, wo mein Fehler liegt?
Achja, mein Controller läuft mit 16Mhz auf 5V und im AvrStudio-Simulator 
scheint der Code ohne Probleme zu laufen...

[Frank L. (franklink)]

Hallo,
wenn die Fehlerbeschreibung die du gepostet hast, tatsächlich so ist, 
wie Du beschreibst, würde ich den Fehler erstmal in sendData suchen, da 
anscheinend dort etwas nicht stimmt.

Gruß
Frank

[Uwe (de0508)]

Was ist/ steht in uart.h und der uart.c ?

Wie sieht dein Makefile aus ?

Läuft evtl. noch eine Watch Doc Timer ?

[Uwe .. (uwegw)]

Was passiert, wenn du in der ISR nicht senddata aufrufst, sondern z.B. 
nur eine LED blinken lässt?

[Cyclon (Gast)]

uart.h

#ifndef UART_H_
#define UART_H_

#define UART_DIR_DDR  DDRD
#define UART_DIR_PORT  PORTD
#define UART_DIR_PIN  PD2

typedef void (*uartRxFnct) (uint8_t*,uint8_t);

void initUart(uartRxFnct rec);
void sendData(uint8_t dst, uint8_t src, uint8_t cmd, uint8_t size, uint8_t *data);


#endif /* UART_H_ */

uart.c

#include <avr/io.h>
#include <avr/interrupt.h>
#include "uart.h"

volatile uartRxFnct g_uartRxFnct;

void send(unsigned char c) {
  while( !(UCSR0A&(1<<UDRE0)) );
  UDR0 = c;
}

void sendData(uint8_t dst, uint8_t src, uint8_t cmd, uint8_t size, uint8_t *data) {
  uint8_t i=0;
  uint8_t crc = 0;

  UART_DIR_PORT |= (1<<UART_DIR_PIN);
  send('#');
  send(size+3);
  send(dst);
  send(src);
  send(cmd);
  for(;i<size;i++) {
    send(data[i]);
  }
  send(crc);
  while( !(UCSR0A&(1<<TXC0)) );
  UCSR0A = (1<<TXC0);
  UART_DIR_PORT &= ~(1<<UART_DIR_PIN);
}


void initUart(uartRxFnct rec) {
  // Configure direction pin for rs485 driver
  UART_DIR_PORT &= ~(1<<UART_DIR_PIN);
  UART_DIR_DDR |= (1<<UART_DIR_PIN);

  UBRR0L = 0x33;  // Set default baudrate to 19200

  UCSR0B = (1<<TXEN0);  // Enable transmitter

  g_uartRxFnct = rec;  // Set receive callback function
}

Makefile gibt's nicht, ist ein Eclipse Projekt mit AVRGCC-Plugin.

Watchdog ist nicht an.

Das mit der LED wird schwirig, da es sich um eine fertige Platine 
handelt, wo ich nicht einfach was anschließen kann. Aber evtl. könnte 
ich einen Eingang vom RS485 Receiver dafür missbrauchen.

[Stefan E. (sternst)]

Cyclon schrieb:
> Die Interrupt-Vektortabelle sieht für mich auch ok aus:

00001800 <__vectors>:

Und wo in deinem Minimal-Code werden die Interrupt-Vektoren in den 
Bootloader-Bereich umgeschaltet?

[stru_aus (Gast)]

mee..

zuerst dachte ich:
-falscher interrupt definiert, das problem hatte ich letztens kurz, dann 
springt der avr immer in einen reset.

aber dann kurz überflogen:
-in der ISR wird eine grosse funktion aufgerufen welche daten ausgibt - 
die wird ewig brauchen, während dessen kommen neue interuppts und 
schwupps ist der stack voll...

empfehlung: nie in einer ISR eine funktion aufrufen, statt dessen nur an 
volatile variablen schrauben.
die zu sendenden daten einfach in einen kleinen ringpuffer schieben, und 
den dann entweder per ISR oder in der main-schleife ausspucken.

[Oliver (Gast)]

stru_aus schrieb:
> -in der ISR wird eine grosse funktion aufgerufen welche daten ausgibt -
> die wird ewig brauchen, während dessen kommen neue interuppts und
> schwupps ist der stack voll...

Alle AVR's blockieren per default weitere Interrupts beim Einsprung in 
eine ISR. Da läuft nix über.

Mit dem Problem desr "ewig dauernden" sendDAta in der ISR hast du zwar 
recht, das führt abe nicht zum o.a. Problem.

Ansonsten gefällt mir die Initialisierungsreihenfolge des Timers nicht.

Prinzipiell sollte man erst die Konfigurationsregister setzen, und dann 
per die Interrupts freigeben.

Stefan Ernst schrieb:
> Und wo in deinem Minimal-Code werden die Interrupt-Vektoren in den
> Bootloader-Bereich umgeschaltet?

Das sieht in der Tat seltsam aus.

Oliver

[Simon K. (simon)]

Ja, für ein normales Programm müssen die Vektoren natürlich an Adresse 0 
liegen. Oder du musst die Interruptvektoren in den Bootloader verlegen.

Dass man in einer ISR keine Funktionen aufrufen darf ist Mumpitz. Da 
darf man eigentlich so gut wie alles machen, was man auch woanders 
machen darf. Bei Atomizität (ATOMIC_BLOCK) und Race Conditions 
(volatile) muss man eben aufpassen.
Überlaufen bei langen Funktionen tut da auch nichts. Es gibt nur ein 
einziges Interruptflag für jeden Interrupt, das zum entsprechenden 
Zeitpunkt gesetzt wird. Und wenn alle Bedingungen erfüllt sind 
(Interrupt aktiviert, globale Interrupts aktiviert, nicht in einer 
aktiven ISR) wird das Flag gelöscht (in der Regel) und der Interrupt 
Vektor ausgeführt.
Wenn nicht, dann eben nicht.