Forum: Mikrocontroller und Digitale Elektronik AVR nach watchdog-Einsatz defekt?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Marco G. (grmg2010)


Bewertung
-1 lesenswert
nicht lesenswert
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ß

von Raten (Gast)


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

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
So wirds sein.

von Marco G. (grmg2010)


Bewertung
-1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


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

von Karl M. (Gast)


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

von Rainer B. (katastrophenheinz)


Bewertung
0 lesenswert
nicht lesenswert

von H.Joachim S. (crazyhorse)


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

von Karl M. (Gast)


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

von Helmut L. (helmi1)


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

von Marco G. (grmg2010)


Bewertung
0 lesenswert
nicht lesenswert
@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)
1
if(eingegengener String == erwarteter String)
2
{
3
 watchdog einschalten
4
 while(1)
5
 {
6
 }
7
}
@ Karl M.
Danke für den Tipp, der war mir aber nicht neu ;)

von H.Joachim S. (crazyhorse)


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

von Karl B. (gustav)


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

von Marco G. (grmg2010)


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

von Nop (Gast)


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

von H.Joachim S. (crazyhorse)


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

von c-hater (Gast)


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

von S. R. (svenska)


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

von Nop (Gast)


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

von Marco G. (grmg2010)


Bewertung
-1 lesenswert
nicht lesenswert
Ich habe jetzt versucht den Reset in der Software zu Implementieren. 
Leider funktioniert es nicht wie gewünscht. Hier mal mein Code:
1
if (strstr(Received_String, "RST"))
2
    {
3
      wdt_enable(WDTO_15MS);
4
      
5
      while(1)
6
      {
7
        
8
      }      
9
    }

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

von Peter D. (peda)


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

von Draco (Gast)


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

von Marco G. (grmg2010)


Bewertung
0 lesenswert
nicht lesenswert
Hatte wirklich nur eine Zeile vergessen:
1
MCUSR = 0; // <-vergessen
2
wdt_disable(); // <- vorhanden, vor der eigentlichen Pin-Init

von c-hater (Gast)


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

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]
  • [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.