Watchdog timer API

The STM32 has two watchdog timers (Independent and Window) … see STM data sheet sec 2.3.15

Question is - will there be API support for them? I’m specifically looking for the fail-safe/reboot watchdog feature so if something goes horribly wrong, it all comes back to life.

If there is no API planned I’m going to need some help with this :wink:

Right now we’re not planning on exposing them but rather using them by default. The default behavior will be that the Independent Watchdog will automatically reboot if anything goes wrong. That way we can ensure, to some extent, that the Core stays connected to the network so that you can reprogram it wirelessly, even if, as you said, something goes horribly wrong…

hey @zach did this watchdog feature ever get implemented? I see references to a couple of watchdog functions in the firmware but they seems to be not enabled. For example I find this comment in main.h which seems to deactivate the watchdog when using the JTAG but I dont see it enabled anywhere else hinting that the watchdog is never running.

 * Use Independent Watchdog to force a system reset when a software error occurs
 * During JTAG program/debug, the Watchdog has to be disabled so that it does not
 * upset the debugger

We had this enabled for a while, but if I remember correctly it ended up causing more problems than it fixed at the time.

Yeah I think that’s correct. Once we work out the connection stability issues we might re-implement the watchdog timer.

FYI: I have some watchdog timer code that @sjunnesson @RWB and I have been mulling over for a bit now and we’re testing it with success so far.

A good watchdog should never be “seen/heard” but always be ready to attack… but until the rest of the code is stable this seems like a good way to keep the Core up and online running our applications.

1 Like

This is an old thread, but I was wondering what the current state of the watchdog is? In my application I would like to have it enabled.

On the Core, the watchdog is enabled, but it is continually “patted” in the 1ms system tick, so in practice it never fires unless something truly catastrophic happens that causes the systick to not function.

On the photon, the watchdog is disabled by default so that stop modes can function without requiring a reset.

We could make a global flag that could be used to disable the constant update of the watchdog in the 1ms timer if that’s useful.

cc: @satishgn

I know this is an old thread but there is little info about how to enable or use the watchdog timers on a Photon…
What is the state of play on this subject please ???.
I am looking for a ‘failure recovery’ mechanism, and a watchdog is the fairly obvious solution.

If the code stops (for any reason) running in the main loop, then I want a watchdog timer to Kick the processor into reset. Yes its a sledgehammer approach, but better that that having a photon - remote so inaccessible (ie I can’t simply press the reset button :wink: - which has just stopped communicating :-((.

IMO we need the API calls as we have no idea whether the underlying hardware is in use by the photon OS :-O. Then if it IS available - we can turn it on IF we want to ;-).

NB I have a project which needs to be 100% operational (as does anything used remotely) - even if it has crashed - it needs to be able to recover… Having just bombed a remote photon and waiting for a user to get home to press the button, I started this watchdog search…:slight_smile: