Watchdog while in sd_app_evt_wait

[Adrian Eggenberger]

Hi

I've discovered last week some unexpected resets by the watchdog. I guess I've the explanation and the workaround for the behavior, but it would be great to have this assumption confirmed. Maybe some other peoples have similar behaviors.

The firmware is built on SDK11 and is based on a simple peripheral project. We have a watchdog configured with a time of five seconds and not running in sleep mode. We establish a connection from a smart device and than do no real data transfer. The call of sd_app_evt_wait by the application never returns, because the application has nothing to do (no interrupt causing the wakeup). After around 80 seconds the system resets caused by the watchdog.

My assumption is, that the softdevice internally wakes up for handling the BLE connection intervals. These ISR's are quite short, but the Watchdog counts up a bit at any wakeup. The application won't reset the watchdog because the call of sd_app_evt_wait never returns.

The solution I have is to configure at least a timer that forces the function sd_app_evt_wait to leave from time to time.

Can someone confirm this behavior? What is the best way to work around it?

Regards Adrian

[RK]

well that wasn't really his problem - because he wasn't stopping advertising etc, he was in connection so it was guaranteed that there would be constant interrupts in the softdevice and the CPU would be coming out of sleep mode on a regular basis, he just wanted to confirm whether those expected short wakeups would increment the watchdog, which they do, without causing sd_app_evt_wait() to return, which they don't.

So you have found a similar thing, expect it takes much longer, which means the chip is only waking up very, very occasionally, and not, as in his case, all the time. So whatever you still do have left on, eg the softdevice enable, is causing the chip to do something and so the WDT counts.

So the solution is to either turn off enough stuff that the chip never wakes at all, or feed the watchdog.

[Quoc Khanh]

Ah yes, you are right. I didn't disable the softdevice. I will try, hope it works. Thank you so much for spending time!

[RK]

and for your case you have a very simple solution also. When you're in your very, very low-power mode, don't use sd_app_evt_wait(), use __wfe(). sd_app_evt_wait() is only an optimised version of __wfe() anyway which filters out system events so you are only 'woken' on user events. Since the events at that point are so rare, it really doesn't matter, so use __wfe() and just feed the watchdog each time. Use sd_app_evt_wait() for the other places in your code where you are advertising or in connection and there will be lots of system events.

[Quoc Khanh]

Actually I'm using: __WFE(); __SEV(); __WFE(); in my code. And the WD is fed every 50ms using a timer when my system is on.

In sleep mode, I turn off all the modules including the timer. Because I thought the WD will be paused in sleep mode when I config:

NRF_WDT->CONFIG = (WDT_CONFIG_HALT_Pause << WDT_CONFIG_HALT_Pos) | (WDT_CONFIG_SLEEP_Pause << WDT_CONFIG_SLEEP_Pos);

Is it true that the WD will pause until the system is woken up from Sleep mode? In my application, sometimes the system needs to sleep for a very long time (some days or even some weeks).

[RK]

Yes it will pause until woken from sleep mode. So you are being woken from sleep mode, hence it's counting very, very slowly because you're being woken very, very occasionally, but you are being woken.

So again, for the n'th time, feed the watchdog. When you are in your low power mode and sleeping for a long, long time with your watchdog timer disabled, any time you are woken up from __wfe(), feed the watchdog, that will prevent any occasional events which are occurring and causing the CPU to run even just a few microseconds, from causing the watchdog reset.

__wfe()
if( in_deep_sleep_mode )
    feed_watchog()