Atmega2561 Watchdog

[A. F. (artur-f)]

Ich habe bis jetzt nach Bedarf mittels

 wdt_enable(WDTO_15MS);

 einen Reset beim Atmega128 auslösen können, nun habe ich auf dem STK 
Board den Atmega128 durch einen Atmega2561 ersetzt. Hier sollte die 
Funktionalität gleich bleiben, jedoch geht der Atmega in einen 
unbestimmten Zustand und reagiert nicht mehr auf die serielle 
Kommunikation.

Im Migration Datenblatt steht folgendes:
The ATmega1281/2561 has the Enhanced Watchdog Timer (WDT), which is 
improved compared to the one in ATmega128. If the WDT is not used, it is 
still recommended to disable it initially in the application code to 
clear unintentional WDT enabled events.
If the operation voltage is 5V and the WDTON fuse is left unprogrammed, 
the WDT will behave similar on both devices. The frequency of the 
Watchdog Oscillator in ATmega1281/2561 is approximately 128 kHz for all 
supply voltages. The typical frequency of the Watchdog Oscillator in 
ATmega128 is close to 1.0 MHz at 5V, but the time-out period increases 
with decreasing VCC. This means that the selection of Time-out period 
for the Watchdog Timer (in terms of number of WDT Oscillator cycles) 
must be reconsidered when porting the design. In ATmega128, the Watchdog 
Timer is either enabled or disabled, while ATmega1281/2561 supports two 
safety levels selected by the WDTON Fuse. The ATmega1281/2561 has a 
watchdog interrupt mode that is not supported in ATmega128. Refer to the 
ATmega1281/2561 datasheet or the Application note "AVR132 - Enhanced 
Watchdog Timer" for more information.


WTD Fuse ist bei meinem Atmega aus, sollte doch wie gewohnt 
funktionieren?

mfg

[Dirk B. (sharandac)]

Hallo,

beim ATmega2561 muss der Watchdog nach einem Watchdogreset wieder 
ausgeschaltet werden, sonst verrennt er sich. Anbei die Funktion wie sie 
auf einen ATmega2561 bei mir funktioniert.

softreset.c

#include <avr/wdt.h>
#include "softreset.h"

// Function Implementation
void softreset( void )
{
  do                          
  {                           
       wdt_enable(WDTO_15MS);  
       for(;;)                 
       {                       
       }                       
  } while(0);
}

// Function Implementation
void wdt_init(void)
{
    MCUSR = 0;
    wdt_disable();

    return;
}

softreset.h

#ifndef _SOFTRESET_H
#define SOFTRESET_H

  // Function Pototype
  void softreset( void );
  void wdt_init(void) __attribute__((naked)) __attribute__((section(".init1")));

#endif /* SOFTRESET_H */

[A. F. (artur-f)]

Danke, krieg gerade keine Verbindung zum Board, kann somit schlecht 
ausprobieren. Werde mich noch mal melden.

vielen Dank.

[A. F. (artur-f)]

Danke, hat funktioniert :)
Wäre vielleicht was für den FAQ.

[Günter R. (galileo14)]

Dirk Broßwick wrote:
> beim ATmega2561 muss der Watchdog nach einem Watchdogreset wieder
> ausgeschaltet werden, sonst verrennt er sich. Anbei die Funktion wie sie
> auf einen ATmega2561 bei mir funktioniert.

Inwiefern verrennt er sich? Bzw. was genau tut er dabei? Kannst Du da 
noch einen Hinweis geben (ist nicht sehr wichtig, interessiert mich 
aber)?

Dieses Watchdog-Problem hat mich gestern und heute viel Zeit gekostet; 
mit Deinem Hinweis habe ich es jetzt gelöst; mir war nicht bewußt, daß 
der Watchdog gleich nach Systemstart deaktiviert werden muß; ich 
verwende dazu folgenden C-Code, der - in etwas anderer Form - im 
Datenblatt steht:

wdt_reset();
MCRSR&=~(_BV(WDRF));
wdt_disable();

Damit funktioniert der Watchdog-Reset einwandfrei.

[Dirk B. (sharandac)]

Hallo,

verrennen trifft es ziehmlich gut. Da der Watchdog nach einem Reset noch 
läuft, löst dieser demzufolge immer noch z.b. alle 15ms einen Reset aus. 
Also hat man nach dem Reset des Controllers genau dieses Zeitfenster 
zeit den Watchdog zu entschärfen, damit dieser genau eben nicht einen 
Reset auslöst. Dazu wird in dem Beispiel der Code für das zurücksetzen 
des Watchdog in die .init1 gepackt, dadurch ist das fast der erste Code 
der nach einem Reset ausgeführt wird. Eigentlich relativ logisch wenn 
man mal drauf gekommen ist :-).

CA Dirk

[ArnF (Gast)]

Schönes Beispiel, wird wohl auch so funktionieren. Aber was ist daran 
ein Softreset. Das ist ein Hardware-Reset, ausgelöst durch Software.

Die Unterscheidung klingt kleinlich, ist es aber nicht unbedingt. Was 
ist, wenn man nach einem Reset prüfen will was passiert ist? Dann kann 
man nicht zwischen Softreset (absichtlicher Reset durch Software) und 
Watchdog (Fehler in Software) unterscheiden.
Außerdem benötigt dieser Softreset etwas Zeit bis er reagiert. Kommt mir 
jetzt bitte nicht mit "15ms ist doch nicht viel Zeit". Es ist genügend 
Zeit für Interrupts. Daher würde ich noch eine Interruptsperre vor dem 
Watchdog-Reset empfehlen.

Leider sind die anderen Resets auch nicht besser, oder erst gar nicht 
durch Software auslösbar.

Wenn es eine kritische Software ist (Leistungsendstufen mit 230V, ...) 
macht es meiner Meinung nach Sinn die Resets "abzufangen" und 
auszuwerten. Außerdem sind bei solch einer Anwendung Softresets äußers 
sinnvoll. Bei einem erkannten Fehlverhalten (z.B. Sollwert stark 
abweichend von Istwert) weiß man oft nicht, ob das Programm oder die 
Hardware schuld ist. Daher lieber einen Softreset in Kauf nehmen und 
alles in einen sicheren Zustand bringen. Dabei lässt sich durch das 
Register MCUSCR unterscheiden zwischen:
Power-on Reset: Normaler Systemstart, alles ist in Ordnung.
External Reset: Kann je nach Anwendung sinnvoll sein, aber meistens wohl 
eher keine Auswertung.
Watchdog Reset: Softwarefehler wie Endlosschleife, Stackoverflow, ...
Brown-out Reset: Unterspannung, kann auch je nach Anwendung interessant 
sein.
JTAG AVR Reset: Schon durch Debugger belegt (JTAG ist doch schon was 
cooles :D).

Ich habe es (noch) nicht ausprobiert, aber mein Ansatz ist folgender:
- Prinzip wie im Beispiel softreset.c/.h (mit Watchdog)
- Interruptsperre, damit auch nur noch der Watchdog schafft
- Muster im Ram halten: ein oder mehrere Bytes auf bestimmten Werten

Durch das Muster kann zwischen eigentlichem Watchdog Reset und Softreset 
unterschieden werden. Voraussetzung ist, dass der Wert auch im Ram 
erhalten bleibt. Dann kann nicht nur ein Softreset erkannt werden, 
sondern je nach Implementierung auch der Grund des Resets (Reset-ID).
Ich bin mir auch nicht sicher wie das am besten geht. static Variablen 
werden immer initialisiert und eignen sich dazu nicht. Bei globalen 
Variablen ohne static bin ich mir grad nicht sicher. Mit denen könnte es 
gehen. Die Register werden "leider" auch alle initialisiert. Bleibt noch 
eine feste Ram-Adresse (uint8_t * const resetid = $xxxx). Da müsste man 
aber sicherstellen, dass die Adresse nicht durch den restlichen C-Code 
belegt wird. Sollte mit bestimmten Ram-Bereichen gehen. Man kann sich 
doch sicherlich einen "protected Ram"-Bereich anlegen.
Sicherlich geht es auch über das EEPROM. Aber das ist wohl etwas 
verschwenderisch, da die Zyklen doch schon gut begrenzt sind.

Ein ganz anderer Ansatz wäre noch ein Sprung auf die Null-Adresse. Wohl 
auch nicht die sauberste Methode, da die Hardware keinen Reset erkennt. 
Zumindest die Software wird aber neu gestartet. Das lässt sich dann auch 
leicht von den anderen Resets unterscheiden, da in MCUSCR die Bits 0 
sind.

Für die meisten Anwendungen ist dieser Ansatz sicherlich oversized, aber 
meiner Meinung nach nicht für kritische Anwendungen.

Jetzt wüsste ich gerne was ihr so dazu einfällt. Was haltet ihr von dem 
Ansatz?

Bei meinem nächsten Projekt werde ich das wohl mal implementieren und 
wenn es jemanden interessiert wohl auch hier posten.

Gruß ArnF

[Denny S. (nightstorm99)]

Hallo!

@ArnF
Ich weiß der Beitrag ist schon etwas älter, aber mich würde
das schon interresieren wie du nun sowas löst?


Gruß Denny

[Daniel (Gast)]

Danke, dieser Thread hat mir auch geholfen, um die Konfusion etwas zu 
lüften hier eine Zusammenfassung, so wie ich es verstanden habe und was 
auch der real vorhandene Controller (ATMega324PA) hier bei mir 
bestätigt:


Neuere ATmega-Controller lassen einen einmal aktivierten Watchdog-Timer 
auch über einen Watchdog-ausgelösten Controller-Neustart hinaus 
weiterlaufen, auch wenn die WDTON-Fuse NICHT aktiviert wurde. (Man würde 
ja eigentlich erwarten, dass die Fuse-Bits auch nach einem per 
Watchdog-Timer ausgelösten Reset genau so gelten wie direkt nach dem 
ersten Einschalten... dem ist aber nicht so.)

Dadurch fällt das Problem hinterhältigerweise beim ersten Programmstart 
und auch solange noch kein Watchdog-Timeout-Reset ausgelöst wurde 
zunächst gar nicht auf.

Das Weiterlaufen des Watchdogs über den Neustart hinaus macht es 
notwendig, am Programmanfang spätestens innnerhalb der eingestellten 
Watchdog-Timeout-Zeit entweder den Watchdog Timer ausreichend früh zu 
resetten oder notfalls (aber dann sinnvollerweise natürlich nur 
temporär) erstmal ganz zu deaktivieren. (eine spezielle Sequenz muss 
hierzu eingehalten werden, siehe Beiträge weiter oben)


Hinweis:
Wenn die Watchdog-Timeout-Zeit kleiner eingestellt ist, als das 
Startup-Delay, wird der Controller (vermutlich (*1) ) permanent neu 
gestartet.  (Watchdog-Timeout 15 ms, Startup-Delay 65 ms)
*1) Ich gehe davon aus, dass der 128 kHz-Watchdog-RC-Oszillator bereits 
startet, bevor der Haupttakt aktiv geschaltet wird.

Wenn das WDTON-Fuse-Bit dabei nicht gesetzt ist, reicht es die 
Stromzufuhr so lange zu unterbrechen, bis alle Elkos auf eine so geringe 
Spannung abgefallen sind, dass der Controller einen frischen 
Power-On-Start durchführt.

Sollte die WDTON-Fuse gesetzt sein, hilft nur noch ein komplettes ERASE 
oder zumindest WDTON Fusebit deaktivieren --- mit dem STK500.exe 
Kommandozeilentool, ggf. 2 Aufrufe direkt nacheinander, den ersten, um 
einen Reset per Reset-Pin auszulösen.

[Dario (Gast)]

Hallo
Wann muss ich die oben gezeigten Funktionen(void softreset() und void 
wdt_init()) im Main-Programm aufrufen?

[Einer K. (Gast)]

Daniel schrieb:
> Neuere ATmega-Controller lassen einen einmal aktivierten Watchdog-Timer
> auch über einen Watchdog-ausgelösten Controller-Neustart hinaus
> weiterlaufen, auch wenn die WDTON-Fuse NICHT aktiviert wurde. (Man würde
> ja eigentlich erwarten, dass die Fuse-Bits auch nach einem per
> Watchdog-Timer ausgelösten Reset genau so gelten wie direkt nach dem
> ersten Einschalten... dem ist aber nicht so.)

Unangenehmer, als der weiterlaufende WDT ist eigentlich, dass dessen 
Prescaler sehr wohl auf default Werte gestellt wird.

Also auf den kleinstmöglichen Wert gestellt wird, egal was da vor dem 
Reset drin stand.

[Cyblord -. (cyblord)]

ArnF schrieb:
> Schönes Beispiel, wird wohl auch so funktionieren. Aber was ist daran
> ein Softreset. Das ist ein Hardware-Reset, ausgelöst durch Software.
>
> Die Unterscheidung klingt kleinlich, ist es aber nicht unbedingt.

Der Watchdog ist nun mal die einzige Möglichkeit per Software einen 
Reset auszulösen. Alle anderen Reset-Quellen benötigen externe 
Beschaltung.
Also was gibts hier zu meckern?
Es wird durch SOFTWARE ein echter Reset ausgelöst. Darum gehts.

[Oliver S. (oliverso)]

Cyblord -. schrieb:
> Es wird durch SOFTWARE ein echter Reset ausgelöst. Darum gehts.

Nee. Es wird durch Hardware ein echter Reset ausgelöst, wenn auch durch 
Software beeinflußbar.

Oliver

[Cyblord -. (cyblord)]

Oliver S. schrieb:
> Cyblord -. schrieb:
>> Es wird durch SOFTWARE ein echter Reset ausgelöst. Darum gehts.
>
> Nee. Es wird durch Hardware ein echter Reset ausgelöst, wenn auch durch
> Software beeinflußbar.

Nö es kommt nur darauf an wie du "ausgelöst" definierst. Und die SW 
entscheidet wann. Damit löst sie aus.