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]

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??

[Jørgen Holmefjord]

Yes, as mentioned at the page you linked: "An interrupt at priority level 0 sets up and performs the flash activity. The CPU is halted for most of the time in this interrupt".

Note that 90ms is the maximum time for a page erase. When I have tested this, I have seen typical times in the range of 2-3 ms for a flash page erase operation to complete.

Whenever the softdevice is enabled, all flash write/erase operations needs to go through the softdevice. The softdevice will schedule flash access according to the priorities described on this page. Performing flash access directly when softdevice is enabled will most likely cause an assert, as the CPU is halted during the operation, preventing the softdevice from handling its timing-critical tasks. FDS runs on top of Fstorage, which have separate backends for use with and without softdevice. The Fstorage softdevice backend will use the softdevice flash API for flash operations.