What is a good value for a watch dog timer?
-
@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.
