Watchdog and sd_app_evt_wait()

[Marten]

Hi,

I have an issue with the watchdog and sd_app_evt_wait() when running the softdevice.
It seems impossible to not let the watchdog go off while having an idle ble connection!
When the timeout is set to 1s and the connection interval at 7.5ms (min), the watchdog goes off and resets the system after +-45s when there is no activity and so sd_app_evt_wait() does not return.
When the timeout is 4s, the watchdog goes off after +-180s. But I cannot guarantee there is "activity" every 180s from the user's phone.

This can be easily reproduced by adding nrf_drv_wdt_init(), nrf_drv_wdt_channel_alloc() and nrf_drv_wdt_enable() to the ble_app_blinky peripheral example and setting  MIN_CONN_INTERVAL to MSEC_TO_UNITS(7.5, UNIT_1_25_MS). Add nrf_drv_wdt_feed() before every call to sd_app_evt_wait() (in power_manage()).
In sdk_config.h: WDT_CONFIG_BEHAVIOUR=0 (pause in sleep and halt), WDT_CONFIG_RELOAD_VALUE=1000 and WDT_ENABLED=1.
After making a connection with nRF Connect (with connection interval 7.5ms) just wait 45s and the watchdog will reset the device!

Is it possible to get some events from the softdevice where I can feed the watchdog, or to configure the softdevice to feed the watchdog ?
The only solution I see would be to add a timer of eg 40s that will feed the watchdog (not from the timer isr context!). But how can I guarantee that this 40s is fast enough ?

A simular question has been raised +2 years ago without a proper answer: watchdog-while-in-sd_app_evt_wait.

I'm using nRF52832 with SDK: 14.0.0 and SD:s132_nrf52_5.0.0

Kind regards,
Marten

[AmbystomaLabs]

I'm really not sure what you are asking.

It seems you want to stop the watchdog once in a while since you are not refreshing it timely.  This would not be consistent with the point of a watchdog which is to go off no matter how screwed up the code was.

If it is going off during normal operations then you just haven't chosen your refresh strategy properly.  You need to find a place in the code that it should always be hitting unless something terrible is wrong.  You can even refresh in multiple places in the code if your device has different operating modes. The wdt doesn't care how often it is refreshed nor where it is refreshed from as long as it happens before time runs out.

[Marten]

Hi,

Thanks for the answer.

See below the simple while(1). The goal of the watchdog is to make sure that all the code called from ProcessEvents() does not take longer than the watchdog timeout (eg 1s)

while(1)
{
    ProcessEvents();
    nrf_drv_wdt_feed();
    sd_app_evt_wait();
}

The issue that I have is that when a user connects with my peripheral device and then just does nothing and waits for 45 seconds, the watchdog resets the system, which is of course not desired. It should be possible to have an idle connection without sending real data over. Thee watchdog should reset the system when my ProcessEvents() function takes too long.

This just because I cannot feed the watchdog, because softdevice does not return from sd_app_evt_wait().

I pause the watchdog while in sleep and halt mode, but apparantly not when softdevice is just sending empty packets.

I hope this clarifies the issue.

Regards,

Marten

[AmbystomaLabs]

It will return from sd_app_evt_wait for any reason at all.  So, even the radio strobing the receiver on an off will wake it up. I doubt the reason for the WDT timeout is due to it not waking up.  More likely it's not returning from ProcessEvents. You should do wdt refresh somewhere or multiple places inside ProcessEvents since you feel that is your core process.

Also, I wouldn't recommend handling the comms like this.  Normally one would have an ISR or a system event drive something as important as communications and not handle it in main.  Generally people do low level housekeeping activities or even nothing at all in main.

Your comment about pausing the WDT while asleep is also a really bad idea.  Again the point of the WDT is to catch the device not waking up.  When a BLE device is idle it is still sending out advertisements or listening.  Either of these wakes it up periodically and thus will cause the WDT to refresh.

The only time the WDT won't run (and this is automatic) is during system off. A return from system off is always a reset by definition. The only thing fun you can do with system off is to keep ram alive and try to pick up where you left off.  Though simpler just to let it do a reset.  Uses less power too if ram is off.

[Marten]

Sorry, but nRF52 has a feature to pause the watchdog while in sleep and/or when halted by the debugger! So not only in system off the watdog doesn't run.

I do know how to handle interrupts and design an embedded product, this is out of the scope of this issue.

I am 100% sure I am returning from ProcessEvents in time, it is sd_app_evt_wait() which is not returning because there is no need for. As said, I just added the watchdog in the blinky app which is doing nothing

Could someone please explain how to add the watchdog in eg the ble_app_blinky peripheral example and using sd_app_evt_wait()? I think it is impossible to do this without having a timer that feeds the watchdog in time (every 40s).

Regards,

Marten

[run_ar]

So the SD will run in the background without notifying the application while advertising or in a connection with only empty packets. This means the wdt timer will run even if the application does not wake up. So, Yes, if your application does nothing for a very long time while the sd is running, you need to have a timer to wake it up in order to feed the wdt.