ATMEGA644p erkennen ob Reset Watchdog Reset war

[Johannes (Gast)]

Hi,

ich habe einen ATMEGA644p und manchmal noch im Programm unerklärliche 
Watchdog Resets.

Nun möchte ich bei Programmstart gerne auswerten ob der letzte Reset vom 
Watchdog Timer ausgelöst wurde, ist das möglich?

Im GCC Programm habe ich folgendes versucht, aber das klappt leider 
nicht :(

int main(void)
{
  uint8_t watchdogreset=0;
  if ((MCUSR & (1<<WDRF))) { watchdogreset=1; } //Wenn Reset Watchdog 
war
  }

Wie kann ich das nun rausfinden?

[Dennis H. (Gast)]

Es gibt ein spezielles Watchdog Interrupt. Das wird aktiv und danach 
kommt ein Reset. Nur darin kannst du herausfinden, ob das ein Watchdog 
reset war. Du kannst natürlich ein EEPROM Wert setzen, würde ich aber 
nicht empfehlen. Braucht man in der Regel nicht.

[Andreas B. (bitverdreher)]

Johannes schrieb:
> aber das klappt leider
> nicht :(

Sollte aber.

[Oliver S. (oliverso)]

Johannes schrieb:
> Im GCC Programm habe ich folgendes versucht, aber das klappt leider
> nicht :(

Was klappt da nicht?
Gib einfach mal das ganze Register aus, denn wenn es kein Watchdog reset 
war, sondern der Klassiker "vergessene ISR", dann siehts du wenigstens, 
daß es gar kein Reset war.

Dennis H. schrieb:
> Es gibt ein spezielles Watchdog Interrupt. Das wird aktiv und danach
> kommt ein Reset. Nur darin kannst du herausfinden, ob das ein Watchdog
> reset war

Das sind wohl eher fake news.

Oliver

[EAF (Gast)]

Johannes schrieb:
> MCUSR

Bootloader?
Ein solcher löscht das MCUSR.
Dann gibts im Programm nix mehr auszuwerten.

[Dennis H. (Gast)]

Oliver S. schrieb:
> Das sind wohl eher fake news.
>
> Oliver

Datenblatt Seite 68 Table 9-1 Vector 9. Was sind daran Fake News. Lies 
das Datenblatt und sei still.

[Andreas B. (bitverdreher)]

Dennis H. schrieb:
> Oliver S. schrieb:
>> Das sind wohl eher fake news.
>>
>> Oliver
>
> Datenblatt Seite 68 Table 9-1 Vector 9. Was sind daran Fake News. Lies
> das Datenblatt und sei still.

Das bezog sich wohl auf die Behauptung man könne dies nur durch den 
Watchdog IRQ herausfinden.
Der übliche Weg ist aber der vom TO beschriebene.

[HildeK (Gast)]

Dennis H. schrieb:
> Was sind daran Fake News.

Man braucht keinen WD-Interrupt. Man kann ihn verwenden, wenn man beides 
machen will: den WD als Timer mit IRQ und als Backup den WD als 
Wachhund.
Also: beschäftige dich mal selber mit dem WD ...

@Johannes: im Anhang ein Beispiel für den Tinyx5. Ohne gesetzte WD Fuse.
Das sollte beim Mega644 nicht viel anders funktionieren (ohne dass ich 
den je in der Hand hatte).

Zur Funktionalität in einer ggf. Arduino-Umgebung kann ich jedoch nichts 
sagen.

[Peter D. (peda)]

EAF schrieb:
> Bootloader?
> Ein solcher löscht das MCUSR.
> Dann gibts im Programm nix mehr auszuwerten.

Nö.
Mein Bootloader fäßt das MCUSR nicht an.

Die Applikation sollte nach dem Lesen des MCUSR es auch zurück setzen. 
Sonst läßt sich der nächste Reset, der kein Power-On ist, nicht 
eindeutig zuordnen.

Ist kein Resetbit gesetzt, dann liegt ein Programmfehler vor (z.B. 
Stacküberlauf), d.h. das Programm läuft wieder in 0x0000 rein.

[Andreas B. (bitverdreher)]

Peter D. schrieb:
> EAF schrieb:
>> Bootloader?
>> Ein solcher löscht das MCUSR.
>> Dann gibts im Programm nix mehr auszuwerten.
>
> Nö.
> Mein Bootloader fäßt das MCUSR nicht an.

Das hätte mich jetzt auch gewundert. Vielleicht gibt solche Bootloader. 
Das wäre dann aber ziemlich sch...e programmiert.

[Der Robs (Gast)]

Johannes schrieb:
> MCUSR

Johannes schrieb:
> if ((MCUSR & (1<<WDRF))) { watchdogreset=1; } //Wenn Reset Watchdog

So mache ich es (erfolgreich) beim Attiny24A schon seit Jahren. Sollte 
also funktionieren.
Nicht ganz unwichtig ist aber zu erwähnen, daß sich dieses Flag nur 
durch einen Power-on Reset zurücksetzt (oder man löscht es von Hand). 
Kommt nach einem Watchdog-Reset irgendwann z.B. ein Brown-Out-Reset, 
dann bleibt das Watchdog-Reset-Flag stehen (zusätzlich natürlich zum neu 
dazugekommenen Brown-Out-Flag), ausser man hat es vorher gelöscht. 
(steht aber im Datenblatt).

Bist Du dir ganz sicher, daß es ein Watchdog-Reset ist, und nicht z.B. 
ein Power-up Reset durch eine wackelige Versorgungsspannung?

Zum debuggen könnte es Sinn machen, zum Programmstart dieses MCUSR Byte 
per UART auszugeben, und dann per
MCUSR = 0;
zu löschen. Dann sollte der Reset-Grund eigentlich immer zu sehen sein.

Gruß und viel Erfolg

Robert

[EAF (Gast)]

Peter D. schrieb:
> Nö.
> Mein Bootloader fäßt das MCUSR nicht an.
OK, deiner nicht.
Kann sein. Weißt du sicherlich genauer als ich.

Allerdings ist die Welt größer:
https://github.com/Optiboot/optiboot/search?q=MCUSR

[c-hater (Gast)]

EAF schrieb:

> Allerdings ist die Welt größer:
> https://github.com/Optiboot/optiboot/search?q=MCUSR

Nunja, optiboot ist jetzt nicht gerade der optimale Bootloader (wie der 
Name suggeriert).

Er maßt sich einfach zu viel an. Z.B. halt, den Boot-Grund zu löschen, 
so dass ihn die App nicht mehr erfragen kann. Das gehört sich nicht für 
einen Bootloader. Der hat immer "minimalinvasiv" zu sein. Die App sollte 
am besten garnicht bemerken können, dass er überhaupt existiert.

Das ist natürlich auf einem AVR8 nicht wirklich vollständig möglich, 
aber ein Bootloader sollte immer versuchen, sich dem Ideal so weit wie 
irgend möglich zu nähern. Und das willentliche Löschen des Resetgrunds 
ist definitiv in diesem Sinne kontraproduktiv.

Naja, für Arduino mag's reichen...