ATmega16 Watchdog Resetquelle erkennen MCUCSR WDRF

[gast (Gast)]

Hallo,

ich komme hier mit einem ATmega16 und seinem Watchdog nicht ganz klar, 
vielleicht könnt ihr mir hier ein wenig unter die Arme greifen.

Auf dem ATmaga16 läuft ein Bootloader der als erstes beim reboot erkennt 
ob es sich um einen Watchdog-Reset handelt. Dies erkenne ich durch das 
WDRF-Flag im MCUCSR wobei ich das Register in einer Variable 
zwischenspeichere wie es in der Doku avrlib vorgeschlagen wird.

Sobald sich ein Fehler im Bootloader befindet und durch den Watchdog 
resettet wird, wird das korrekt erkannt.

Wurde aber vom Bootloader die eigentliche Firmware gestartet und in 
dieser tritt dann ein Watchdog-Reset auf, wird das nicht erkannt.

Ich hoffe ich hab mich verständlich ausgedrückt und ihr könnt mir 
weiterhelfen.

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

Vielen Dank im Voraus.

[Oliver (Gast)]

>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

[Oliver (Gast)]

.. zu früh abgeschickt.

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

Oliver

[Peter D. (peda)]

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

Üblicher Weise geht man davon aus, daß ein Bootloader getestet ist, da 
er sich nicht selber überschreiben kann. Eine Fehlerkorretur ist daher 
nicht mehr möglich.

Also ignoriert der Bootloader den Watchdog und damit gehört er der 
Applikation. Ist der Watchdog aktiv, wird er vom Bootloader nur 
getriggert, damit der Download nicht abgebrochen wird.

Der Bootloader wertet auch das MCUCSR nicht aus. Ihm ist es egal, ob er 
durch ein Power-On oder durch die Applikation per Watchdogreset 
gestartet wurde. Es ist dadurch auch ein Update möglich, ohne das Gerät 
auszuschalten.


Peter

[gast (Gast)]

@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.

[gast (Gast)]

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:

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

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

void get_mcucsr(void)
{
  mcucsr_mirror = MCUCSR;
  MCUCSR = 0;
  wdt_disable();
}

int main(void)
{
  if bit_is_set(mcucsr_mirror, WDRF)
  {
    // LED an
  }
  wdt_enable(WDTO_2S);
  wdt_reset();
  ...
  jmp firmware
  ...
  return 0;
}

Die Firmware sieht prinzipiell so aus:

int main(void)
{
  wdt_enable(WDTO_2S);
  wdt_reset();
  // LED aus
  while (1)
  {
    _delay_ms(10);
  }
  return 0;
}

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.

[Peter D. (peda)]

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

Darf ja auch nicht, der Bootloader hat es ja gelöscht.

Wie gesagt, wenn der Watchdog der Applikation gehören soll, darf der 
Bootloader das MCUCSR nicht löschen !!!

Der Bootloader braucht den Watchdog auch nicht, da er ja getestet sein 
sollte.


Peter

[gast (Gast)]

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

[Oliver (Gast)]

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

[gast (Gast)]

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.

[Oliver (Gast)]

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

Oliver

[gast (Gast)]

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.

[Karl H. (kbuchegg)]

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

Dir ist aber klar, dass dieser Schuss nach hinten losgehen kann?
Deine Leute in der Produktion werden es dir danken, wenn deine Steuerung 
nach einem 3/4 Jahr nicht mehr funktioniert, nur weil es in diesem 
Zeitraum 10 Neustarts wegen Watchdog gegeben hat.

Nicht jede auf den ersten Blick gute Idee ist auch wirklich gut.

[Peter D. (peda)]

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


Es ist aus Deinem Schnipselchen aber nicht ersichtlich, wie Du das 
machst.

Und auch, ob die Applikation überhaupt weiß, wo sich das Byte befindet 
und daß sie es nicht anfassen darf.

SW-Fehler lassen sich ohne den Code nunmal nicht lösen.

Bei solchen komplexen Sachen ist ein compilierbarer Code als Dateianhang 
immer besser.
Und natürlich auch die speziellen Make-Einstellungen.


Peter

[Wolfgang Horn (Gast)]

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

[Oliver (Gast)]

>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

[gast (Gast)]

Hier die Firmware:

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

#include <avr/wdt.h>
#include <avr/eeprom.h>
#include <util/delay.h>

int main(void)
{
  wdt_enable(WDTO_2S);
  wdt_reset();
  if (eeprom_read_byte((uint8_t *) 0x0016) != 0x01)
  {
    eeprom_write_byte((uint8_t *) 0x0016, 0x01);
  }
  while (1)
  {
//    wdt_reset();
    _delay_ms(10);
  }
}

[Peter D. (peda)]

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

Und was ist denn überhaupt der Fehler?

Dieses Programm schreibt nur ne 1 an Adresse 22.
Völlig egal was der Watchdog oder die Resetquelle macht.


Peter


P.S.:
Es kann sein, daß der Compiler Adresse 0 nicht benutzt und es an Adresse 
23 schreibt.

[gast (Gast)]

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.

[Oliver (Gast)]

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

[Peter D. (peda)]

Ick sach ma, diese endlose Schnipseljagd bringt uns nicht einen Jota 
weiter.
Benutze den Dateianhang und poste zur Abwechslung endlich mal was 
richtiges.

Und wenn das EEPROM-Rumgemache keinen Effekt hat, dann mußt Du uns auch 
nicht damit verwirren.
Also alles unnötige raus!
Nicht auskommentieren, sondern löschen!

Und natürlich noch die standard Problembeschreibungspunkte:
- wie funktioniert das Programm?
- was soll wann wie passieren?
- was passiert statt dessen?


Was macht denn überhaupt das (".noinit") und (".init3")?
Was spricht dagegen, es ganz profan im Main auszulesen?


Peter

[Oliver (Gast)]

>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

[gast (Gast)]

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.