Verwendung Watchdog

Die Argumente in den Links sind einleuchtend aber ich glaube etwas übertrieben. Lt. Datenblatt vom Atmega328 besitzt der interne WD einen eigenen Oszillator, wg Unabhängigkeit.
Wenn ich mir ein Szenario ausmale wo die Gefahr besteht dass ein wild gewordenes Programm den Watchdog ausschaltet, dann bin ich nicht mehr weit davon entfernt eine Risikoanalyse durchzuführen und die Lebensdauer der Taster zu berechnen...
Ein externe WD darf dann nicht mehr auf den Reset Pin vertrauen, sondern soll gleich die Stromversorgung des Arduino trennen. Galvanisch getrennt natürlich.
Vielleicht liege ich falsch aber bis jetzt hat bei mir der interne WD immer super funktioniert. Immer wenn ich dem internen WD die Schuld geben wollte, war es doch nur ein Programmierfehler.
Bei wem von euch hat der interne WD schon einmal richtig versagt?

@Kduin:
Zeige uns doch bitte Deinen Code.

Bei Dir hat er schon versagt - und zwar durch Programmierfehler :wink: Genau das war ja der Punkt des Autors.

ids2001:
Zurück zum Watchdog. Ich hätte eh nur einen Reset erst nach Ablauf von >10sec eingestellt. Hierzu dürfte es ja eigentlich nie zu Konflikten mit dem Bootloader kommen..... oder?

lg
dieter

Hallo, also diese Frage hat sich irgendwie verlaufen deshalb hänge ich sie nochmals hoch,eventl kann mir sie jemand beantworten.

Lg

Falls keine Signale auf der seriellen Schnittstelle anliegen würde ich das auch so sehen. Falls auf der seriellen Schnittstelle aber - warum auch immer - Signale anliegen, dann kann es Dir passieren, dass der Bootloader vor dem WD drankommt und danach gleich wieder ein Reset durch den WD ausgelöst wird. Wenn Du einen WD verbaust ist es eigentlich immer besser den Bootloader in die Tonne zu treten und einen ISR zum flashen zu nehmen.

@ UdoKlein
Du hast natürlich recht mit den Programmierfehlern. Allerdings waren die „Programmierfehler“: 1. WD vergessen zu setzen, 2. WD zum debuggen deaktiviert. Somit hat der WD selbst nicht versagt.
Bei einem externen WD mit Jumper wäre mir das genauso passiert.

@ids2001
Es wird vermutlich zu Konflikten kommen. Lese dir:
AVR-Tutorial: Watchdog – Mikrocontroller.net (Hat mir UdoKlein damals empfohlen, Danke im Nachhinein)
Vor allem „WDT nach einem Reset“. Ich hatte mit einem Atmega328 genau das Problem. Erst WD auf 8 Sekunden eingestellt. Nach einem WD Reset war der WD auf eine sehr kurze Zeit (15ms ?) eingestellt. Keine Chance für den Bootloader.

Mit dem -DWATCHDOG_MODS Parameter gibt es kein Problem.

Hmm, dann hast Du aber noch den alten Bootloader. Der neue ist da etwas fixer unterwegs. Davon abgesehen empfehle ich heute ja den Bootloader ganz in den Tonne zu treten :wink:

darf ich an dieser stelle mal eine Frage zum Verständnis stellen? Ist der Bootloader nur dafür da um Code per USB zu empfangen? wenn ich einen ISP benutzen würde (geht hier auch ArduinoISP?) könnte ich also auch ganz normal in der Arduino IDE programmieren und hätte mehr Speicher frei?

Genau das. Und wenn Du einen AVRispMKII nimmst, dann kannst Du die Brenngeschwindigkeit auch auf 2 MHz hochdrehen, dann geht noch dazu das Brennen sehr viel schneller. Etwa Faktor 10. Und weiterhin kannst Du dann den seriellen Monitor beim Flashen offen lassen weil er sich ja nicht mehr mit AVRDude ins Gehege kommt.

Bootloader sind hauptsächlich billig. Wer effizient entwickeln will kommt bald davon los.

aber angenommen die brenngeschwindigkeit ist mir egal, dann kann ich ohne bootloader mittels ArduinoISP-sketch auf einen Atmega328 ohne Bootloader brennen? wähle ich dann dazu trotzdem Arduino Uno als board aus?

UdoKlein ich muss Dir leider widersprechen. Ich habe soeben den Bootloader der Version 101 auf einen 328er gebrannt (Nano). Ohne die DWatchdogMods Option.
Nach dem Auslösen des WD ist der Chip Blockiert. Es lassen sich keine weiteren Sketche aufspielen. Der Chip kommt nicht einmal dazu über Serial etwas auszugeben.
Nach einem kurzen Trennen der Stromversorgung ist der WD (noch) nicht aktiv. Damit kann man über den Bootloader einen neuen Sketch aufspielen. Somit entkommt man der Falle, die man sich selbst gestellt hat. Ich glaube jedoch dass es nicht sinnvoll ist einen WD einzusetzen der nur den Chip blockieren kann. wg. Ausfallsicherheit usw :slight_smile:
Leider habe ich keinen Uno mehr frei um dasselbe damit zu testen.
Ich bleibe vorerst bei meiner DWatchdogMods Option. Lasse mich jedoch gerne eines Besseren belehren.

@ Voralpenkreuz
Habe das selbe Problem mit dem 1.1 Bootloader auf einem Nano & Pro Mini. Nach einem WD-reset hängt er im Bootloader fest. WDT = 8s
Wie hast Du denn deinen DWatchdog Mod eingebunden?

im Arduino Unterverzeichnis:
hardware\arduino\bootloaders\atmega
in der Datei:
makefile
beim entsprechenden Target bei:
CFLAGS +=
den Parameter:
'-DWATCHDOG_MODS'
hinzufügen

Beispiel für den Mega:
mega: CFLAGS += '-DMAX_TIME_COUNT=F_CPU>>4' '-DNUM_LED_FLASHES=0' -DBAUD_RATE=57600 '-DWATCHDOG_MODS'

Hex-Datei sichern, und aus dem Verzeichnis entfernen. Danach den Bootloader neu kompilieren (make.exe…)und via ISP auf den Chip brennen.

@voralpenkreuz: ich versteh jetzt gerade nicht warum Du mir widersprechen musst. Ich sagte doch, dass Bootloader eh gerne Ärger machen. Dann sagst Du, Du hast auch einen Fall bei dem Du damit Ärger hast.

Wo liegt der Widerspruch? Oder stehe ich gerade auf dem Schlauch?

Hallo Udo,
mein Widerspruch bezog sich damals auf den Beitrag Nr. 16.
Auch wenn der neue Bootloader „fixer“ ist, so ist er nicht schnell genug.

Ärger habe ich keinen gehabt. Habe nur getestet ob das Watchdog-Problem bei einem Chip mit dem neuesten unmodifizierten Bootloader noch immer auftritt. Und das tut es leider.

Mittlerweile brenne ich auf jeden neuen Chip sofort den geänderten Bootloader weil:
Nur 1 Kabel. RX und TX brauche ich beim Debuggen sowieso. Bei eingebauten Arduinos muss nur ein billiges USB-Kabel zugänglich sein. Beim Netbook brauche ich keinen USB Hub usw…

Bis jetzt sind mir keine Nachteile durch den DWatchdogMods-Parameter bekannt.
Deshalb frage ich mich:
Warum wird der offizielle Bootloader auf die Chips nicht gleich mit den DWatchdogMods gebrannt???

Weil die Zielgruppe meistens keine Watchdogs verwendet. Die Mods sind eine kleine inkompatible Änderung mit zweifelhaftem Nutzen. Wer einen WD nutzt sollte den Bootloader weglassen. Ansonsten riskiert man immer Probleme falls der Bootloader glaubt etwas auf der seriellen Schnittstelle zu erkennen. Hatte ich aber schon gesagt.

Signale auf der Schnittstelle sind kein Problem für den Bootloader, wenn der µC durch den Watchdog resettet wird. In diesem Fall wird der Bootloader ja übersprungen. Also horcht der BL gar nicht ob Signale anliegen.

Bei einem manuellen Start/Reset kann dies ein Problem sein. Allerdings verzögert der Bootloader den µC Start dann nur oder blockiert der Bootloader den Chip wenn keine sinnvollen Signale ankommen?

Und: Inwiefern sind die mods inkompatibel?

Und: Inwiefern sind die mods inkompatibel?

  1. Mods ändern das Verhalten des Codes. Wenn Du eine Plattform anbietest, dann kannst Du nur wenig Annahmen über die Verwender machen. Von daher ist jede Verhaltensänderung im Zweifelsfall kritisch.

  2. Mods ändern den binären Code und damit Prüfsummen die darüber gebildet sein könnten.

  3. Mods ändern Einsprungvektoren falls jemand mit dem Bootloader "ferkelt".

Das sind alles Auswirkungen die in Deinem Fall nicht zum Tragen kommen. Aber für ein Plattformprodukt findet sich immer Einer der doch neben der "richtigen" Spur gearbeitet hat.

Danke für die Infos.
Jetzt wo die Nachteile bekannt sind, habe ich kein schlechtes Gewissen mehr.

Hallo,

leider funzt der ganz oben verlinkte Code nnicht mehr.

Suche einen Link zu nem Watchdog..

Gruß Chris