AVR nach watchdog-Einsatz defekt?

[Marco G. (grmg2010)]

Moin,

ich bin gerade dabei einen ATMEGA644 zu programmieren. Bei diesem wollte 
ich den watchdog mit 2.7V benutzen. Dies funktioniert leider nicht. Ich 
habe jetzt nur die Fuse gesetzt. Muss ich noch irgendetwas in Software 
beachten? Ich hatte das Problem, nachdem ich den watchdog programmiert 
hatte, lief mein Programm nicht mehr, trotz stabiler 3.3V. Ich hatte den 
watchdog dann bei den Fuses entfernt, bis ich einmal die Versorgung 
abgeschaltet hatte war der watchdog aber anscheinend noch aktiv.

Was war mein Fehler in diesem Fall?

Gruß

[Raten (Gast)]

Für mich klingt das eher das du die brown out detection setzen wolltest 
und nicht den Watchdog? Was wolltest du damit erreichen?

Kann es sein das du jetzt den Watchdog aktiviert hast und ihn keine 
passende Zeichenfolge sendest und der Watchdog deswegen noch der 
eingestellten Zeit deinen Prozessor immer resetet?

[H.Joachim S. (crazyhorse)]

So wirds sein.

[Marco G. (grmg2010)]

Stimmt. Hatte irgendwie beides zusammengeworfen. :( Ist natürlich 
Quatsch. Trotzdem bräuchte ich neben der BOD auch noch einen 
Softwarereset. Dafür eignet sich der watchdog ja eigentlich ganz gut. 
Wie mache ich das am elegantesten? wenn er über die uart einen 
bestimmten string empfängt geht er in einen programmabschnitt, der 
solange wartet, bis der watchdog auslöst?

[Arduino Fanboy D. (ufuf)]

Marco G. schrieb:
> Trotzdem bräuchte ich neben der BOD auch noch einen
> Softwarereset.
Wofür braucht man bei einem AVR einen "Softwarereset".
Ich habe die Frage schon oft gehört, aber noch nie einen echten Grund.

[Karl M. (Gast)]

Hallo,

wie "bedienst" Du denn den WatchDocTimer während des Programm laufs?

Wie schnell springt der WatchDocTimer an und resetet den AVR µC ?

Du musst nun strikt nicht blockierend dein Programm gestallten und 
"lange" Delays sind ab sofort nicht mehr erlaubt.

Das gilt an vielen Stellen, (LCD Grafik) Ausgaben, UART RX/TX usw.

Man findet sich i.A. in einer Endlosschleife wieder, die ein 
deterministisches Zeitverhalten hat und haben muss !

Marco G. schrieb:
> Wie mache ich das am elegantesten? wenn er über die uart einen
> bestimmten string empfängt geht er in einen programmabschnitt, der
> solange wartet, bis der watchdog auslöst?

Das muss Du bitte noch erklären ?
Wieso soll der AVR µC resetten ?

[Rainer B. (katastrophenheinz)]

http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_softreset.html

[H.Joachim S. (crazyhorse)]

Benutzt du den watchdog denn sonst im "normalen" Programm?
Wenn nicht, startest du den dann einfach und schickst das Programm in 
eine Endlosschleife.
Wenn ja nur Endlosschleife (while(1);)

[Karl M. (Gast)]

Vielleicht für Dich ein neuer Tipp,

wenn man einen AVR µC wirklich einem Hardware Reset aussetzen möchtet,
dann verbindet man den /Reset Eingang mit einem GPIO Pin und zieht 
diesen auf low.
Der Rest kommt dann von selbst.

[Helmut L. (helmi1)]

Marco G. schrieb:
> Ich hatte den
> watchdog dann bei den Fuses entfernt, bis ich einmal die Versorgung
> abgeschaltet hatte war der watchdog aber anscheinend noch aktiv.

Das ist so gewollt. Wenn du die Watchdog-Aktiv Fuse zuruecksetzt muss du 
die Versorgungsspannung kurz abschalten sonst bleibt der Aktiv. Kann man 
so auch im Datenblatt nachlesen.

[Marco G. (grmg2010)]

@Rainer B
Danke für den Link.

@H.Joachim Seifert
Nein, normalerweise wird er im normalen Programm nicht benutzt. Es soll 
nur die Möglichkeit geben den uC über BT zu reseten, da über diese 
Schnittstelle auch einige Konfigurationen vorgenommen werden können, bei 
denen ich es für besser halte einen "vernünftigen" Reset zu benutzen als 
eine Updatefunktion der entsprechenden Register.
Wäre das das so in etwa was du gemeint hattest? (Pseudocode)

if(eingegengener String == erwarteter String)
{
 watchdog einschalten
 while(1)
 {
 }
}

@ Karl M.
Danke für den Tipp, der war mir aber nicht neu ;)

[H.Joachim S. (crazyhorse)]

Jo, genauso.
Ich benutz das auch, um den Bootlader aus der Applikation zu starten.

[Karl B. (gustav)]

Hi,

Marco G. schrieb:
> wenn er über die uart einen
> bestimmten string empfängt geht er in einen programmabschnitt, der
> solange wartet, bis der watchdog auslöst?

könnte IMHO so gehen. Er initialisiert dann aber die Schnittstelle 
(UART) wieder neu. (MCU sollte bei   .org 0x0000 wieder anfangen.)
siehe auch:
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_Watchdog

ciao
gustav

[Marco G. (grmg2010)]

@H.Joachim Seifert
Ok, dann werde ich das mal so implementieren. Scheint eine ganz robuste 
Lösung dafür zu sein.
@Karl B.
Das ist in Ordnung, dass die Schnittstelle neu initialisiert wird. Das 
wird auf der Gegenseite berücksichtigt.

[Nop (Gast)]

Arduino F. schrieb:
> Wofür braucht man bei einem AVR einen "Softwarereset".

Für dasselbe wie bei jedem anderen Microcontroller auch. Um das System 
neu zu starten beispielsweise. Typischer Anwendungsfall: Alles auf 
Werkseinstellungen setzen und dann neu starten.

Oder um das System in einen kontrollierten Zustand zu kriegen, wenn die 
Applikation sich aufhängt. Dafür ist ein Watchdog gedacht.

[H.Joachim S. (crazyhorse)]

Netterweise kannst du die Resetquelle am Programmstart auch noch 
feststellen und unterscheiden, ob es nun ein PowerOn oder der (in deinem 
Fall gewollte) watchdog der Auslöser ist.

[c-hater (Gast)]

Nop schrieb:

> Für dasselbe wie bei jedem anderen Microcontroller auch. Um das System
> neu zu starten beispielsweise. Typischer Anwendungsfall: Alles auf
> Werkseinstellungen setzen und dann neu starten.
>
> Oder um das System in einen kontrollierten Zustand zu kriegen, wenn die
> Applikation sich aufhängt. Dafür ist ein Watchdog gedacht.

Komisch. Beides kriege ich problemlos immer auch ohne Watchdog hin. Oder 
eigentlich nur Punkt 1. Denn Punkt 2 tritt überhaupt erst garnicht auf, 
wenn man einfach mal die Bugs in der verschissenen Anwendung sucht und 
beseitigt, bevor man sie auf die Menschheit losläßt...

[S. R. (svenska)]

c-hater schrieb:
> Denn Punkt 2 tritt überhaupt erst garnicht auf,
> wenn man einfach mal die Bugs in der verschissenen Anwendung sucht und
> beseitigt, bevor man sie auf die Menschheit losläßt...

Erstens: Abhängig von der Anwendung und der Umgebung, in der sie läuft, 
ist "Bugs finden" garnicht so einfach. Ist die Bugsuche teurer als der 
mögliche Schaden durch den Bug mal der Anzahl des Auftretens, lohnt sie 
sich zudem nie.

Zweitens: Abhängig von den Kosten (Schäden), die ein möglicherweise 
existierender, aber nicht entdeckter Bug verursachen kann, ist ein 
Watchdog als Failsafe durchaus sinnvoll. Formale Verifikation ist eine 
Sache, IoT und TTM eine andere.

[Nop (Gast)]

Ich mache das auf STM32, aber AVR kann sowas ja auch.

Wenn beim Hochfahren die Reset-Analyse ergibt, daß der Watchdog die 
Ursache ist und nicht vor dem Reset gespeichert wurde, daß ein 
absichtlicher Watchdog-Reset stattfinden soll, dann wird das im 
Fehlerspeicher geloggt.

Dadurch weiß man überhaupt erst, daß ein Problem vorhanden ist, welches 
man debuggen muß. Und nein, nicht alle Applikationen sind ein bißchen IO 
und fertig, wo das mehr oder weniger trivial testbar ist.

Mitunter tauchen solche Issues auch erst bei Dauerbetrieb nach ein, zwei 
Monaten auf. Im Testfeld wird aber, damit die Tests überhaupt 
reproduzierbar sind, zwischen den Testfällen das Gerät neu gestartet.

Das wird dann regelmäßig ein Gehacke zwischen Kunde ("geht nicht"), 
Entwicklern ("geht im Labor"), Testfeld ("alles bestanden") und Finance 
("fürs Rumstochern auf Verdacht gibt's kein Budget"). Klingt häßlich, 
aber das ist doch die Realität.

Gib dem Kunden mit so einem Fehlerlog die Möglichkeit, das zu belegen, 
dann ist zumindest dieses Pingpong beendet, und es ist klar, da muß was 
gemacht werden.

[Marco G. (grmg2010)]

Ich habe jetzt versucht den Reset in der Software zu Implementieren. 
Leider funktioniert es nicht wie gewünscht. Hier mal mein Code:

if (strstr(Received_String, "RST"))
    {
      wdt_enable(WDTO_15MS);
      
      while(1)
      {
        
      }      
    }

Leider hängt der Controller dann komplett fest und ich muss ihn neu 
programmieren anstelle eines Resets. Habe ich noch eine Zeile vergessen?

[Peter D. (peda)]

Marco G. schrieb:
> Leider hängt der Controller dann komplett fest

Wenn man partout nicht ins Datenblatt schauen will, kann man das auch in 
der <wdt.h> nachlesen:
"
    Note that for newer devices (ATmega88 and newer, effectively any
    AVR that has the option to also generate interrupts), the watchdog
    timer remains active even after a system reset (except a power-on
    condition), using the fastest prescaler value (approximately 15
    ms).  It is therefore required to turn off the watchdog early
    during program startup, the datasheet recommends a sequence like
    the following:
"
usw.

[Draco (Gast)]

Arduino F. schrieb:
> Marco G. schrieb:
>> Trotzdem bräuchte ich neben der BOD auch noch einen
>> Softwarereset.
> Wofür braucht man bei einem AVR einen "Softwarereset".
> Ich habe die Frage schon oft gehört, aber noch nie einen echten Grund.

Ich hatte ein :-D

Atmega32u4, Reset des µC zum einfachen Disconnect und Wechsel des 
USB-Descriptor und Reconnect mit diesem. Und sonst, zum Reset und 
Wechsel in den Bootloader wird das auch oft genutzt.

[Marco G. (grmg2010)]

Hatte wirklich nur eine Zeile vergessen:

MCUSR = 0; // <-vergessen
wdt_disable(); // <- vorhanden, vor der eigentlichen Pin-Init

[c-hater (Gast)]

Draco schrieb:

> Ich hatte ein :-D
>
> Atmega32u4, Reset des µC zum einfachen Disconnect und Wechsel des
> USB-Descriptor und Reconnect mit diesem.

Ich hätte noch Verständnis dafür, wenn man das mit V-USB (oder einer 
vergleichbaren Soft-USB-Implementierung) so löst.

Wer das hingegen mit einem 32U4 so lösen muss, der kann einfach mal nur 
nicht programmieren. Oder ist schlicht zu faul dazu, es richtig zu 
machen...

War wohl im per C&P "geschriebenen" "eigenen" Code so nicht 
vorgesehen...