What is a good value for a watch dog timer?
-
I've been digging into the Arduino's watchdog and I'm wondering what a good watchdog reset timer value is. At the moment I'm thinking about 2s. All of my nodes go through the mainloop within milli seconds.
I've giving it a good thought. And I want to add the wdt to all of my nodes. So okay a node should never stall if you're code is good and your sensors are connected properly. But there are reasons which you can't prevent, that might cause the Arduino to stall. I'll be using the wdt just as a safety measurement. Not as a reason to do crappy coding.
-
I've been digging into the Arduino's watchdog and I'm wondering what a good watchdog reset timer value is. At the moment I'm thinking about 2s. All of my nodes go through the mainloop within milli seconds.
I've giving it a good thought. And I want to add the wdt to all of my nodes. So okay a node should never stall if you're code is good and your sensors are connected properly. But there are reasons which you can't prevent, that might cause the Arduino to stall. I'll be using the wdt just as a safety measurement. Not as a reason to do crappy coding.
-
@TheoL You should not go below 2s if you have repeater functionalities enabled (the transport logic implements a few random delays of up to 1s to minimize tx collisions).
@tekka is there any downside to use the maximum of 8 seconds? What I mean is that I don't think there is any case that will be caught with 2 seconds but won't get caught with 8 seconds, and that 6 secod delay will not affect much either.
From my experience, nodes tend to either work or die, not much in between.
-
@tekka is there any downside to use the maximum of 8 seconds? What I mean is that I don't think there is any case that will be caught with 2 seconds but won't get caught with 8 seconds, and that 6 secod delay will not affect much either.
From my experience, nodes tend to either work or die, not much in between.
-
@mfalkvidd No, shouldn't matter - I'm also using 8s as default timeout.
-
@TheoL You should not go below 2s if you have repeater functionalities enabled (the transport logic implements a few random delays of up to 1s to minimize tx collisions).
-
@tekka thank you. It was my guessing. 1 second would in my case be enough. I only scan 4 binary input's. But better save than sorrow. Can I light up an led in an wdt interrupt handler? So that I know that the watchdog went of?
-
@tekka is there any downside to use the maximum of 8 seconds? What I mean is that I don't think there is any case that will be caught with 2 seconds but won't get caught with 8 seconds, and that 6 secod delay will not affect much either.
From my experience, nodes tend to either work or die, not much in between.
@mfalkvidd I just scan 4 inputs and send their values to my gateway if one has changed. I could do 4 seconds. But My main loop really doesn't take more than a couple of ms. Including the message sending.
Wouldn't this be a great addition to MySensors? It could be done, since MySensors 2 takes over the main loop of a sketch
-
@TheoL Yes in theory possible, the watchdog can be programmed to trigger an IRQ before resetting - this is used in hwSleep() - but tricky :)
@tekka I just have to hook up some logger device and do a serial write. I'm gonna think about this.
I used pieces from an example I found online:
#include <Arduino.h> #include <avr/wdt.h> /* watchdog timer example code. flashes LED three times quickly on boot up. Then goes thru a loop delaying an additional 250ms on each iteration. The LED is on during each delay. Once the delay is long enough, the WDT will reboot the MCU. */ const int onboardLED = 13; void setup() { int k; // immediately disable watchdog timer so set will not get interrupted wdt_disable(); // I often do serial i/o at startup to allow the user to make config changes of // various constants. This is often using fgets which will wait for user input. // any such 'slow' activity needs to be completed before enabling the watchdog timer. // the following forces a pause before enabling WDT. This gives the IDE a chance to // call the bootloader in case something dumb happens during development and the WDT // resets the MCU too quickly. Once the code is solid, remove this. delay(2L * 1000L); // enable the watchdog timer. There are a finite number of timeouts allowed (see wdt.h). // Notes I have seen say it is unwise to go below 250ms as you may get the WDT stuck in a // loop rebooting. // The timeouts I'm most likely to use are: // WDTO_1S // WDTO_2S // WDTO_4S // WDTO_8S wdt_enable(WDTO_4S); // initialize the digital pin as an output. // Pin 13 has an LED connected on most Arduino boards: pinMode(onboardLED, OUTPUT); // at bootup, flash LED 3 times quick so I know the reboot has occurred. for (k = 1; k <= 3; k = k + 1) { digitalWrite(onboardLED, HIGH); delay(250L); digitalWrite(onboardLED, LOW); delay(250L); } // delay a bit more so it is clear we are done with setup delay(750L); } void loop() { int k; // this loop simply turns the LED on and then waits k*250ms. As k increases, the amount of time // increases. Until finally the watch dog timer doesn't get reset quickly enough. for (k = 1; k<= 10000; k = k + 1) { // at the top of this infinite loop, reset the watchdog timer wdt_reset(); digitalWrite(onboardLED, HIGH); delay(k*250L); digitalWrite(onboardLED, LOW); delay(250L); } }But this http://forum.arduino.cc/index.php?topic=63651.0 explains it all.
-
@tekka I just have to hook up some logger device and do a serial write. I'm gonna think about this.
I used pieces from an example I found online:
#include <Arduino.h> #include <avr/wdt.h> /* watchdog timer example code. flashes LED three times quickly on boot up. Then goes thru a loop delaying an additional 250ms on each iteration. The LED is on during each delay. Once the delay is long enough, the WDT will reboot the MCU. */ const int onboardLED = 13; void setup() { int k; // immediately disable watchdog timer so set will not get interrupted wdt_disable(); // I often do serial i/o at startup to allow the user to make config changes of // various constants. This is often using fgets which will wait for user input. // any such 'slow' activity needs to be completed before enabling the watchdog timer. // the following forces a pause before enabling WDT. This gives the IDE a chance to // call the bootloader in case something dumb happens during development and the WDT // resets the MCU too quickly. Once the code is solid, remove this. delay(2L * 1000L); // enable the watchdog timer. There are a finite number of timeouts allowed (see wdt.h). // Notes I have seen say it is unwise to go below 250ms as you may get the WDT stuck in a // loop rebooting. // The timeouts I'm most likely to use are: // WDTO_1S // WDTO_2S // WDTO_4S // WDTO_8S wdt_enable(WDTO_4S); // initialize the digital pin as an output. // Pin 13 has an LED connected on most Arduino boards: pinMode(onboardLED, OUTPUT); // at bootup, flash LED 3 times quick so I know the reboot has occurred. for (k = 1; k <= 3; k = k + 1) { digitalWrite(onboardLED, HIGH); delay(250L); digitalWrite(onboardLED, LOW); delay(250L); } // delay a bit more so it is clear we are done with setup delay(750L); } void loop() { int k; // this loop simply turns the LED on and then waits k*250ms. As k increases, the amount of time // increases. Until finally the watch dog timer doesn't get reset quickly enough. for (k = 1; k<= 10000; k = k + 1) { // at the top of this infinite loop, reset the watchdog timer wdt_reset(); digitalWrite(onboardLED, HIGH); delay(k*250L); digitalWrite(onboardLED, LOW); delay(250L); } }But this http://forum.arduino.cc/index.php?topic=63651.0 explains it all.
@TheoL On AVR, one could also read the content of MCUSR (at the right moment) - this is a status register that holds the reset cause (i.e. watchdog reset, brownout reset, external reset, power-on reset). However, the bootloader has to support this function...
-
@TheoL On AVR, one could also read the content of MCUSR (at the right moment) - this is a status register that holds the reset cause (i.e. watchdog reset, brownout reset, external reset, power-on reset). However, the bootloader has to support this function...
-
@bjacobse No, this is not true. Sketch uploads are handled via bootloader which in turn takes care of wdt reset (please have a look at e.g. optiboot source). That said, it is in any case advisable to either disable or reset wdt during setup().
-
Also the stock bootloader is broken so that in reboot, it sets the watchdog timer to a very small value (so that a reboot would happen before the sketch has done 'setup()'), but does not turn off the watchdog it it was enabled in the sketch -> eternal reset loop if you ever reboot from a watchdog-enabled sketch.
Optiboot, MYSBootLoader etc. would work fine.
-
Also the stock bootloader is broken so that in reboot, it sets the watchdog timer to a very small value (so that a reboot would happen before the sketch has done 'setup()'), but does not turn off the watchdog it it was enabled in the sketch -> eternal reset loop if you ever reboot from a watchdog-enabled sketch.
Optiboot, MYSBootLoader etc. would work fine.
-
@bjacobse No, this is not true. Sketch uploads are handled via bootloader which in turn takes care of wdt reset (please have a look at e.g. optiboot source). That said, it is in any case advisable to either disable or reset wdt during setup().
-
@tekka
you are actually right, I have removed my post to avoid confusing people.
https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot.c#L829@bjacobse Yes, wdt business can be quite confusing :)
Optiboot has a sophisticated wdt approach: wdt is only enabled if the MCU is reset externally (this is the case when you upload a new sketch from the IDE), in all other reset cases (i.e. watchdog-, brownout- and power-on reset), the wdt is disabled and optiboot directly hands over to the sketch.See here for the conditions: https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot.c#L484-L485
And here it gets disabled:
https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/optiboot.c#L847This also means that with optiboot, wdt is always disabled when the sketch starts (if WDON fuse is unset).
And to give a heads up for the MYSBootloader 1.3 release: wdt will be on by default (at the moment 4s), and the user has to either disable or reset it in the sketch. This is a safety mechanism and the only way to remotely recover from a bad/faulty FW.
