Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Development
  3. What is a good value for a watch dog timer?

What is a good value for a watch dog timer?

Scheduled Pinned Locked Moved Development
17 Posts 5 Posters 4.9k Views 4 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • TheoLT 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?

    tekkaT Offline
    tekkaT Offline
    tekka
    Admin
    wrote on last edited by
    #7

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

    TheoLT 1 Reply Last reply
    0
    • mfalkviddM mfalkvidd

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

      TheoLT Offline
      TheoLT Offline
      TheoL
      Contest Winner
      wrote on last edited by
      #8

      @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

      1 Reply Last reply
      0
      • tekkaT tekka

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

        TheoLT Offline
        TheoLT Offline
        TheoL
        Contest Winner
        wrote on last edited by
        #9

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

        tekkaT 1 Reply Last reply
        0
        • TheoLT 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.

          tekkaT Offline
          tekkaT Offline
          tekka
          Admin
          wrote on last edited by tekka
          #10

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

          TheoLT 1 Reply Last reply
          1
          • tekkaT 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...

            TheoLT Offline
            TheoLT Offline
            TheoL
            Contest Winner
            wrote on last edited by
            #11

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

            1 Reply Last reply
            0
            • bjacobseB Offline
              bjacobseB Offline
              bjacobse
              wrote on last edited by bjacobse
              #12

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

              tekkaT 1 Reply Last reply
              0
              • bjacobseB bjacobse

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

                tekkaT Offline
                tekkaT Offline
                tekka
                Admin
                wrote on last edited by tekka
                #13

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

                bjacobseB 1 Reply Last reply
                1
                • T Offline
                  T Offline
                  ToniA
                  wrote on last edited by
                  #14

                  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.

                  tekkaT 1 Reply Last reply
                  0
                  • T 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.

                    tekkaT Offline
                    tekkaT Offline
                    tekka
                    Admin
                    wrote on last edited by
                    #15

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

                    1 Reply Last reply
                    0
                    • tekkaT 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().

                      bjacobseB Offline
                      bjacobseB Offline
                      bjacobse
                      wrote on last edited by bjacobse
                      #16

                      @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

                      tekkaT 1 Reply Last reply
                      0
                      • bjacobseB 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

                        tekkaT Offline
                        tekkaT Offline
                        tekka
                        Admin
                        wrote on last edited by tekka
                        #17

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

                        1 Reply Last reply
                        3
                        Reply
                        • Reply as topic
                        Log in to reply
                        • Oldest to Newest
                        • Newest to Oldest
                        • Most Votes


                        11

                        Online

                        11.7k

                        Users

                        11.2k

                        Topics

                        113.1k

                        Posts


                        Copyright 2025 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                        • Login

                        • Don't have an account? Register

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • MySensors
                        • OpenHardware.io
                        • Categories
                        • Recent
                        • Tags
                        • Popular