Watchdog on Ethernet Gateway

[axillent]

@BulldogLowell why not to play around with your own copy of the sources?

with success you can be a contributor of this nice feature

[tekka]

@axillent said:

second wdt_reset need to be embedded into many places across sketch and library sources

It's in general good practice to enable the watchdog to avoid deadlocks. What works best in my experience is to set the wdt to 8s and reset the wdt timer at the beginning of the main loop (as long as it takes max. 8s).

Important: Avoid blocking functions and delay() - substitute delay() for mysensors::wait(), where the wdt is reset.

The problems with the ethernet shield W5100 are discussed everywhere, resetting the arduino won't help in that case, but rather implementing an external watchdog that power-cycles the shield...

[BulldogLowell]

@axillent said:

you can be a contributor of this nice feature

OK, I'll give it a stab.

@tekka said:

What works best in my experience is to set the wdt to 8s and reset the wdt timer at the beginning of the main loop (as long as it takes max. 8s).

you mean generally, or you are using it already on this application?

[tekka]

@BulldogLowell both, i'm using the wdt with Optiboot and MYSBootloader. Reading MCUSR during bootloading will give a hint on the reset cause...

[tekka]

Here a simple sketch:

#include <avr\wdt.h>

void setup() {
  // set watchdog to 8s
  wdt_enable(WDTO_8S);
}

void loop() {
  // watchdog reset
  wdt_reset();
  
  // do some stuff that does not take longer than 8s
 // else watchdog will trigger
}

[BulldogLowell]

@tekka said:

Here a simple sketch:

yes, got that far ;) I thought you meant you had it working on a gateway.

Working with the (as @axillent said) the gateway, with all of its nuances and making it extensible for (the majority?) of the standard sensor sketches would be the challenge.

[axillent]

@BulldogLowell setting watchdog to timeout after 8 seconds can support you in most situations without a need to dig into library source

But you will be not guaranteed from all cases, it is possible that your arduino will be reset in normal situation where reset is not needed. But actually the same will happen if you will attach external watchdog as you state in you first post here

[BulldogLowell]

@axillent said:

But you will be not guaranteed from all cases, it is possible that your arduino will be reset in normal situation where reset is not needed. But actually the same will happen if you will attach external watchdog as you state in you first post here

I have a lot more flexibility with hardware, i believe.... there is an (8s) limit on the Atmel watchdog, no?

[axillent]

@BulldogLowell said:

I have a lot more flexibility with hardware, i believe.... there is an (8s) limit on the Atmel watchdog, no?

it is a limit of atmega328, other MCU can differ

but it is still possible to organize longer period by activating WDT ISR handler
this will be not the best practice but it will work
the best practice is to set very short timeout and to put wdt_reset() at all required points

[hek]

What happens with watchdog while sleeping?

[axillent]

@hek said:

What happens with watchdog while sleeping?

it depends on what do you want :)
if i'm not mistaken LowPower library you are using is using watchdog while sleeping
actually watchdog is only one timer running while POWER_DOWN
it is a common way to wake up because of watchdog event from the deepest sleep if you need to wake up by time, not by external event

[Gambituk]

Hi, i would be interested in any more updates along this line. In my case my gateway is mostly stable as far as i can tell. several weeks without issues. My problem is that most of my nodes seem to lockup, so i would be totally interested in making them more robust either by software or if necessary with external chip as overlord watchdog

[Dan S.]

@BulldogLowell Any progress on this? My Ethernet gateway is quite reliable after solving power supply issues and implementing soft spi. But about once a month it stops and rebooting it makes it operative again. The failure seems to be periodic--once a month. May be a clue there--something reaching a limit? At any rate, any failure rate where I can't start it up without physically rebooting is too much.

[maha]

millis() has a rollover after approximately 50 days. Could that be something?

[Dan S.]

@maha Don't know. But your question did trigger the thought of using milils() to periodically trigger a reboot. Rather than check for a lockup with a watchdog routine I may try just rebooting it at a shorter time interval, e.g., every 2 weeks, than I have experienced the lockups using millis to measure the interval.

[Dan S.]

Added a 8 sec Watchdog to my ethernet gateway and it's up and running now. Time will tell if it cures the occaisional lockups by automatically resetting. Will report back the results

[hek]

FYI: Watchdog reset is automatically called by process() nowadays in the development-branch.

https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/MySensor.cpp#L509

[Dan S.]

@hek I assume this is with the intent to allow a watchdog reset on sensor sketches in the future, but does not apply to the Ethernet gateway sketch?

[Dan S.]

@hek Please disregard my prior message. I looked further and see that the watchdog reset is part of the sensor wait routine and is in the current 1.4 version of MySensors.cpp

[Dan S.]

It's been over 6 weeks since I added an 8 sec watchdog to my Ethernet gateway (to Vera) and have not had to reboot the gateway since then. Before adding the watchdog, the most it ever lasted before without rebooting was 4 weeks. So for now I have to assume that the watchdog is doing its job and automatically restoring the gateway. If so, then it is providing the gateway dependability that I wanted. Time will tell.