ATmega16 Watchdog Resetquelle erkennen MCUCSR WDRF

>Die bisherigen Threads im Forum sowie der Artikel über den Watchdog
>haben mich hierbei leider nicht weitergebracht.

Das wundert nicht, schließlich ist das von dir beschriebene Verhalten so 
nicht erklärbar. Dem watchdog ist es herzlich egal, wann und wo er 
zuschlägt, es wird immer mit gesetztem Flag im MCUCSR-Register ein Reset 
ausgelöst.

Bist du sicher, daß der wd nicht in der Firmware deaktiviert ist und gar 
nicht zuschlägt, bzw. der Reset nicht vom wd kommt, sondern woanders 
her, und dazu die ISR feht?

Oliver

.. zu früh abgeschickt.

...sondern ein Interrupt ausgelöst wird, und dazu die ISR feht?

Oliver

@Oliver
Der Watchdog ist in der Firmware aktiviert, das sehe ich da der 
Bootloader ne Nachricht schickt wenn der ATmega rebootet.

Der Bootloader läuft ohne Interrupts und die Testfirmware hat auch keine 
aktiviert.

Der ATmega ist in den Fusebits so programmiert das er bei einem Reboot 
automatisch den Bootloader an Adresse 0x3800 startet.

Der Bootloader sieht prinzipiell so aus:

1

uint8_t mcucsr_mirror __attribute__ ((section (".noinit")));

2

3

void get_mcucsr(void) __attribute__((naked)) __attribute__((section(".init3")));

4

5

void get_mcucsr(void)

6

{

7

  mcucsr_mirror = MCUCSR;

8

  MCUCSR = 0;

9

  wdt_disable();

10

}

11

12

int main(void)

13

{

14

  if bit_is_set(mcucsr_mirror, WDRF)

15

  {

16

    // LED an

17

  }

18

  wdt_enable(WDTO_2S);

19

  wdt_reset();

20

  ...

21

  jmp firmware

22

  ...

23

  return 0;

24

}

Die Firmware sieht prinzipiell so aus:

1

int main(void)

2

{

3

  wdt_enable(WDTO_2S);

4

  wdt_reset();

5

  // LED aus

6

  while (1)

7

  {

8

    _delay_ms(10);

9

  }

10

  return 0;

11

}

Da der Watchdog in der Mainschleife nicht geresettet wird schlägt der 
Watchdog zu aber wie gesagt das WDRF Flag ist nicht gesetzt.

Ändere ich den Bootloader und schicke ihn in ne Endlosschleife statt dem 
Start der Firmware schlägt der Watchdog auch zu aber hier wird das WDRF 
Flag gesetzt.

Ich sichere es doch in einem anderen Byte bevor ich es lösche. Oder 
nicht?

Ich kann mich nur wiederholen, wenn direkt nach einem Reset das WDRF-Bit 
nicht gesetzt ist, wurde der Reset nicht durch den Watchdog ausgelöst. 
Egal, ob Bootloader vorhanden, oder nicht.

>Der Bootloader läuft ohne Interrupts und die Testfirmware hat auch keine
>aktiviert.

Wenn überhaupt kein Reset-Flags in MCUCSR gesetzt ist, bleibt ausser 
einem irrlichternden ínternem Interrupt nicht viel als Ursache übrig.

Oliver

Der Bootloader soll praktisch erkennen das die Firmware vom Watchdog 
geresettet wurde und diese nach x Resetts nicht mehr starten.

Die Firmware interessiert es nicht wie oder warum es einen Resett 
gegeben hat.

Danke für euere Mühe.

Hast du denn mal die anderen Reset-Flags überprüft?

Oliver

Ja, die anderen Reset-Flags funktionieren und werden korrekt erkannt.

Externer Reset und Brown-out habe ich schon getestet.

In dem speziellen Fall das die Firmware resettet wird steht allerdings 0 
im Register.

Hi, Peter,

Du: "Der Watchdog kann nur einem gehören. Entweder dem Bootloader oder 
der Applikation."

Das ist mir unverständlich. Weil Bootloader und Applikation niemals 
zugleich ablaufen - jedenfalls im AVR.

Sondern der Bootloader kann den WD aktivieren, dann wird er rechtzeitig 
zurückgesetzt oder löst einen Reset aus.
Genauso, wenn Bootloader seine Schuldigkeit getan und die Anwendung 
aufgerufen hat.

Ein Wechselspiel, wie es "gast" wohl vorschwebt, habe ich mit einer 
Zustandsvariablen im EEPROM realisiert. Natürlich so, dass nur in 
Ausnahmefällen geschrieben wird.

Ciao
Wolfgang Horn

>In dem speziellen Fall das die Firmware resettet wird steht allerdings 0
>im Register.

Kannst du das Testprogramm (Bootloader und Firmware) hier vollständig 
kompilierbar zeigen?

Oliver

Hier die Firmware:

Ich habe sie komplett zusammengekürzt, aber mit ihr tritt der Fehler 
genauso auf.

1

#include <avr/wdt.h>

2

#include <avr/eeprom.h>

3

#include <util/delay.h>

4

5

int main(void)

6

{

7

  wdt_enable(WDTO_2S);

8

  wdt_reset();

9

  if (eeprom_read_byte((uint8_t *) 0x0016) != 0x01)

10

  {

11

    eeprom_write_byte((uint8_t *) 0x0016, 0x01);

12

  }

13

  while (1)

14

  {

15

//    wdt_reset();

16

    _delay_ms(10);

17

  }

18

}

Diese Firmware wird durch den Watchdog rebootet weil in der Schleife 
wdt_reset() nicht aufgerufen wird.

Der ATmega16 rebootet also.

Durch den Reboot wird der Bootloader gestartet. Wenn ich im Bootloader 
das  WDRF Flag im MCUCSR Register prüfe, dann ist das nicht gesetzt.

Die Frage ist warum ist es nicht gesetzt.

Alle anderen Flags werden in dem Register ja gesetzt wenn ein 
entsprechendes Ereignis aufgetreten ist.

eeprom...

Welche WinAVR-Version bzw. avrlibc-Version nutzt du?

Es gibt da eine (?) Version mit einem Bug in den eeprom-Routinen, die 
erzeugen ungewollte Interrupts.

(Genaugenommen steckt der Bug im Silikon, die avrlibc umgeht ihn nur 
nicht. Details stehen in den AVR-errata).

Oliver

>Durch den Reboot wird der Bootloader gestartet. Wenn ich im Bootloader
>das  WDRF Flag im MCUCSR Register prüfe, dann ist das nicht gesetzt.

>Die Frage ist warum ist es nicht gesetzt.

Nein. Das ist nicht die Frage, und war sie auch noch nie.
Nach einem WD-Reset ist das WDRF-Flag gesetzt. Immer. Punkt.
So kaputt kann der AVR gar nicht sein, daß nur dieses eine Flag komisch 
rumspinnt.

Die Fragen können sein:
Wer löst den Reset bzw. den Sprung auf den Reset-Vektor aus, wenn nicht 
der WD?
Wer oder was löscht das MCUCSR-Register, bevor du da dran kommst?
Warum klappt das Auslesen des Registers nicht?

Oliver

Hallo,

Vielen Dank für euere Mithilfe.

Ich habe das Problem gefunden und behoben. Aus irgendeinem Grund war der 
Bootloader nicht mehr in der Bootloadersektion sondern im normalen 
Firmwarebereich. Somit wurde beim flashen der Firmware ein Teil des 
Bootloaders überschrieben.

Da die Testfirmware sehr klein ist hatte das wohl nur diese doofe 
Auswirkung.