Watchdog Timer Implementation

[Charan]

Hello, 

I am transmitting 1 byte BLE data across a central and peripheral and the central does other things like control PWM, sample SAADC (scan mode), GPIO pins interrupts etc. I need to ensure that my application is not stuck while doing any of those tasks or in any of the event handlers and hence, I want to implement a watchdog timer.

What is the ideal way for using the watchdog in such a case or in other words when should I kick the dog in such an application. I though of having a watchdog at start of every event handler and disabling at end of event handler but if SoftDevice interferes while running the SAADC event handler, the dog wont be kicked and the system will be reset.

Thanks in advance

[Jørgen Holmefjord]

Hi,

Your suggested solution sounds fine to me, if you do not need system-level watchdog, but only cares about certain interrupts/functions/tasks. The softdevice will have the highest priority in your application, so you will always have to account for the softdevice interrupts when calculating/measuring the maximum worst-case delay for the Watchdog timeout. You can find the timing specifications for softdevice interrupts in Processor usage patterns and availability in the softdevice specifications.

Best regards,
Jørgen

[Jørgen Holmefjord]

Yes, using app_timer or a separate RTC instance should work.To make sure that the watchdog prevents lockups at any interrupt priority, you can set a flag in the RTC/app_timer handler (which runs in interrupt context) and kick the dog in the main loop if the flag is set.

[Charan]

Hmm Ok

Is it possible to create two watchdog timer, one for every event handler and one which is in system level (so that softdevice isn't stuck). 

[Jørgen Holmefjord]

No, there is only a single Watchdog timer instance available in the chip. Why would you need additional Watchdog for the event handlers if you also have a system-level watchdog running?

[Charan]

Jørgen Holmefjord said:

Why would you need additional Watchdog for the event handlers if you also have a system-level watchdog running?

I wanted to monitor each and every event handler separately but yes, as you said that would be redundant given that I have a system level timer. Although, why should I set a flag and trigger in main() for a system-level watchdog. Suppose, I directly kick the dog in the timer handler and if midway through that particular timer_handler() softdevice interrupts, once the softdevice is done with it's execution, wouldn't it come back to that timer_event handler and finish it's process??

[Jørgen Holmefjord]

There is no problem with feeding the watchdog in interrupt context if you only want to prevent lockups in higher priority interrupt tasks. The problem first arises if you get a lockup in main thread or an interrupt context with lower priority than where you feed the watchdog.

Lets say that you decide to feed the watchdog using app_timer, and you run app timer at priority 5. If you now get a lockup in a handler running at priority 0-5, the app_timer interrupt will not be able to run, as you are already stuck in a higher priority interrupt. This will lead to a watchdog timeout and will trigger a reset. If you get a lockup at priority 6-7, or in the main thread, the app_timer interrupt will preempt the execution of the thread where the lockup happens, to feed the watchdog. Since the watchdog is feed as normal, you will not get a watchdog timeout, and the watchdog is therefore ineffective for the lower priority tasks.

[Charan]

Ok, I got the idea now. And if I am not wrong, the main() will only be executed once whenever the CPU wakes up right?

[Jørgen Holmefjord]

You need to put an endless loop inside main(). If you do not do this, the CPU will continue executing random code from flash until it crashes.

The loop can be used to execute tasks when other tasks are idel, or you can put the CPU into sleep (System ON mode) to save power.

[Charan]

Ok, I read in the forums that if I have any code in main() and call nrf_pwr_mgmt_run(), the code inside main() will execute for every event. Now if kick the dog inside main itself, that should suffice right?

[Jørgen Holmefjord]

Yes, that should be fine.

[Charan]

Hello, 

In this website, its written that interrupt processing when erasing a flash page is 90ms. Does that mean that the control will be with the softdevice for the whole 90ms? 

Moreover, when is this used? Peer manager uses the fds library right?? So, when will the softdevice use the flash. For storing bond information??