Watchdog not watchdogging?

[alowhum]

Last night the smart alarm clock I'm working on froze, and thus didn't wake me up.

I quickly added a watchdog this morning (was on the to-do list). Then the radar motion sensor had a wire issue, and got disconnected and reconnected. The device froze again.

No problem, I thought, the watchdog is probably already doing its thing.

But it stayed frozen.

Are there limits to the watchdog function of the Arduino Nano?

[bjacobse]

If you use the standard bootloader from Arduino the WD is dsabled, flash with optiboot

[alowhum]

Ah! So that's it!

I'll look into it. Thanks for the tip!

Is there any way to activate it without resorting to a different bootloader?

[mtiutiu]

@alowhum

It's not portable but for the AVR architecture you can use:

void before() {
  wdt_disable();
  wdt_enable(WDTO_8S); // 8s timeout 
}

void loop() {
  wdt_reset();
}

Other watchdog options for the AVR architecture here.

[mfalkvidd]

Be aware that some of the MySensors functions (sleep and according to below link also send) will change the watchdog settings, so you'll have to set back the watchdog after using these functions.

Enhancement request: https://github.com/mysensors/MySensors/issues/1160

EDIT: no, that's not what issue 1160 is about. 1160 is about setting up the watchdog so that sketch developers don't need to add custom code to enable the watchdog. Sorry for confusing everyone.

[alowhum]

@mfalkvidd Could you elaborate a bit on what MySensors does to the watchdog? Does it disable it? The above seems to imply I have to re-enable it after every send command? That sounds almost unbelievable.

On github a quick search for "wdt_disable" in the code only reveals disabling it when sleep() is called?

There I can understand its presence.

The node mentioned in the first post already had an AVR watchdog enabled in the manner described. It doesn't use sleep. Still, it didn't seem to reboot. So maybe it's true, and I just haven't found the code in the search?

[mfalkvidd]

@alowhum I don’t know unfortunately. But what you’re saying sounds reasonable.

[Yveaux]

@alowhum I don't have easy access to the code atm, but, as I read it, the change request @mfalkvidd refers to suggests to add a wdt reset to the send() function. It doesn't say the current send() fiddles with the wdt.

[mfalkvidd]

I've done some digging.

Sending I_DEBUG message to the node will call hwCPUFrequency which does things to the watchdog, but it looks like the watchdog settings are saved and then restored afterwards.

Sleep uses the watchdog to wake up. When the node is sleeping on timer, it needs to use the watchdog because all other clocks are stopped when sleeping so there is no other way to keep time.

I guess it would be possible to save and restore the watchdog settings in hwPowerDown, just like in hwCPUFrequency? That should allow the user to set their own watchdog which is a good start.
EDIT: MySensors already saves and restores the watchdog during sleep. Reference link.

I guess it would be even better if it was possible to enable the watchdog when not sleeping, using a define (like suggested in the linked github issue). But I am not sure endless reboots (which is a risk with the watchdog enabled) is desirable, so that feature might need to be off by default. I also don't know if it is possible to detect the reset reason and handle boot differently (which might be desirable).

All this is for AVR only. I am not sure about the other platforms supported by MySensors.

And thanks Yveaux for clarifying he send() behavior. I was very confused by that statement in the github issue. I guess resetting the watchdog in wait() and any other long-running function would make sense. But why would send() take so long time that the watchdog might be tripped?

[Yveaux]

@mfalkvidd I suppose the best place to kick the watchdog in the MySensors stack would be the doYield(), as it also keeps the esp8266 watchdog alive.

[mfalkvidd]

@yveaux seems like it is supposed to kick the watchdog already:

@remark Internally it will call yield, kick the watchdog and update led states.

https://github.com/mysensors/MySensors/blob/06bdb991b6012c3cc9a2306a09b4a4b92105e9f0/core/MySensorsCore.h#L261

https://github.com/mysensors/MySensors/blob/06bdb991b6012c3cc9a2306a09b4a4b92105e9f0/core/MySensorsCore.cpp#L551 calls hwWatchdogReset which, on avr, resets the watchdog https://github.com/mysensors/MySensors/blob/bde7dadca6c50d52cc21dadd5ee6d3623be5f3c6/hal/architecture/AVR/MyHwAVR.h#L62

[dbemowsk]

What about a hardware watchdog such as this 555 based watchdog. A hardware based watchdog seems a bit more reliable.
http://upperbound.com/projects/555-watchdog-timer/

[bjacobse]

@dbemowsk said in Watchdog not watchdogging?:

What about a hardware watchdog such as this 555 based watchdog. A hardware based watchdog seems a bit more reliable.
http://upperbound.com/projects/555-watchdog-timer/

the watchdog in AT328 is reliable, do you have documentation behind this comment that it's not?

[dbemowsk]

@bjacobse I have just seen things in forums in the past like this where some users explain about the possibility of the microcontroller with the software based watchdog timer hanging to the point where the MC's internal watchdog hangs too. That was my basis for the comment.

[bjacobse]

This link is misleading which causes misunderstanding
The ATmega328p have watchdog timer build in, which if enabled uses an internal RC oscillation, and this will for sure reset the MCU, if the timer isn't reset by the user program before time-out. it works rock stable...
Something that can cause unreliability is that brown-out detecting of power voltage, will also cause a shutdown, and if the designer isn't aware of stable power voltage, then you get unstable MCU system...

http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf

Below snippet is from above ATmega328 spec:

Please note there are 3 Operating modes:
– Interrupt
– System Reset
– Interrupt and System Reset
In Interrupt mode, the WDT gives an interrupt when the timer expires. This interrupt can be used to wake the
device from sleep-modes, and also as a general system timer. One example is to limit the maximum time
allowed for certain operations, giving an interrupt when the operation has run longer than expected.
In System Reset mode, the WDT gives a reset when the timer expires. This is typically used to prevent system hang-up in case of runaway code. The third mode, Interrupt and System Reset mode, combines the other two modes by first giving an interrupt and then switch to System Reset mode. This mode will for instance allow a safe shutdown by saving critical parameters before a system reset.

[EDIT] below removed as it was not correct, comment from mfalkvidd is correct, that mysensors is using WDT for wakup-call

[mfalkvidd]

@bjacobse no that is not the reason.

In sleep mode, MySensors uses the watchdog to wake up every 8 seconds to increment a counter and immediately go to sleep. This is the most power efficient way to sleep for a set time. Because no other clocks are active in sleep mode, it is impossible to keep time without using the watchdog.

[mfalkvidd]

I have now checked the code for sleep, and the watchdog settings are saved and restored: https://github.com/mysensors/MySensors/blob/121648f34bb45ab0e21fc4b4835959d27b28a9c6/hal/architecture/AVR/MyHwAVR.cpp#L93

So it seems like it should be possible for sketch developers to define their own watchdog, which will be active att all times except:

• briefly after receiving an I_DEBUG message
• during sleep()

@alowhum would you mind posting your sketch?

[bjacobse]

@mfalkvidd
This just shows how clever/smart the mysensors code are developed :-)

[mgaman]

This is an old issue related to bootloader problems on some nano/mega boards.
Try this
https://bigdanzblog.wordpress.com/2014/10/23/installing-the-optiboot-loader-on-an-arudino-nano-to-fix-the-watch-dog-timer-wdt-issue/

[tiana]

See this project, there have solution for hardware based watch dog, can be easily transform to be usable for Arduino.

https://www.openhardware.io/view/636/Raspberry-PI-Hat