What is a good value for a watch dog timer?

[tekka]

@mfalkvidd No, shouldn't matter - I'm also using 8s as default timeout.

[mfalkvidd]

@tekka sorry, I meant to direct that comment to @TheoL
But thanks for responding :)

[TheoL]

@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]

@TheoL Yes in theory possible, the watchdog can be programmed to trigger an IRQ before resetting - this is used in hwSleep() - but tricky :)

[TheoL]

@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]

@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]

@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]

@tekka Wow! That's a nice one. I should be able to do this in the setup and just log it to serial. Thank you.

[bjacobse]

[EDIT] removed post since it was wrong and should not confuse

[tekka]

@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().

[ToniA]

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.

[tekka]

All AVRs (mini, ebay china) I've obtained had optiboot programmed - how about others?

[bjacobse]

@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

[tekka]

@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#L847

This 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.