www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega2561 Watchdog


Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 */

Autor: A. F. (artur-f) Benutzerseite
Datum:

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

vielen Dank.

Autor: A. F. (artur-f) Benutzerseite
Datum:

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

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ArnF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Denny S. (nightstorm99)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.