Wisblock-API watchdog

Does Wisblock-API solution include a watchdog timer, if so, how is it configured? Is there a recommendation how to setup a WDT for this solution to ensure reliable communication with equipment that is unattended in the field for years…I have found that the Adafruit SleepyDog library seems to work with RAK4631/nRF52 if needed.

There is no watchdog implementation in the WisBlock-API right now. But it is a good idea.

Will look into it, or if you have an implementation already I would like to see it.

Hello Bernd,
I have successfully added a WDT to the Wisblock API example by simply doing the following:

  1. Platform IO: Add Adafruit Sleepydog library to my project
  2. Add the include file to app.h
#include <Adafruit_SleepyDog.h>
  1. Initilaize the WDT in the user function init_app()

Now the question is from a LoRa standpoint where should we issue the WDT reset?


A. If the product boots but fails to join a network. I see that the library already re-tries the join process, so maybe we reset the WDT with each join attempt, but once we reach the max re-tries (or some higher number of failed re-tries) we no longer reset the WDT so it will reboot the device and start all over?
B. If the product fails to send LoRa uplinks periodically. This can be more difficult because if the time between uplink messages is long (ie. hours), the WDT will most likely not support it.

I will think through possible ways this can be implented. Is there a general ‘idle task’ in the API that could be used for this sort of housekeeping functionality?

Thinking today about different applications and was as well looking into the watchdog library.

The watchdog might be applicable if you have a send interval of a few minutes. In this case you can implement the Watchdog.reset(); in the app_event_handler() function and adjust the watchdog timer to the send interval time.

For longer send intervals, e.g. a soil moisture sensor that sends only every 2 hours or an application that sends only on a specific event, it will be difficult to integrate without waking up the MCU to just to reset the watchdog.

I think I will not integrate the watchdog as default, but instead add an example that shows the usage of the watchdog library.

Thanks Bernd,
We will wakeup the mcu every minute to reset the WDT. Looking into the WDT code the timeout mSec period is defined as an int type, however if I send 120000 mSec as an argument it seems to work, any idea why it doesn’t wrap around the 32767 max of int type and clobber the WDT itself?

int does not mean it is 16bit. I think it depends on the MCU.

I do not use int ever, in my code it is int8_t, int16_t, int32_t, so it is clear what the size is.

Anyway a bad idea to use a signed value for the time. Bad coding style imho (maybe coming from Java).

Waking up every 1 minute might be ok for battery consumption, needs some testing (which takes time)

1 Like