Watchdog Timer Implementation

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Wed, 03 Mar 2021 14:17:38 GMT

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.

RE: Watchdog Timer Implementation

Charan — Wed, 03 Mar 2021 12:21:00 GMT

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

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Tue, 23 Feb 2021 11:58:47 GMT

Yes, that should be fine.

RE: Watchdog Timer Implementation

Charan — Tue, 23 Feb 2021 11:37:39 GMT

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?

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Fri, 19 Feb 2021 15:03:34 GMT

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.

RE: Watchdog Timer Implementation

Charan — Fri, 19 Feb 2021 13:43:44 GMT

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?

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Fri, 19 Feb 2021 10:06:49 GMT

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.

RE: Watchdog Timer Implementation

Charan — Fri, 19 Feb 2021 07:33:25 GMT

[quote userid="14926" url="~/f/nordic-q-a/71624/watchdog-timer-implementation/295020#295020"]Why would you need additional Watchdog for the event handlers if you also have a system-level watchdog running?[/quote]

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

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Thu, 18 Feb 2021 09:17:28 GMT

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?

RE: Watchdog Timer Implementation

Charan — Thu, 18 Feb 2021 07:30:36 GMT

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).

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Tue, 16 Feb 2021 09:36:28 GMT

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.

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Tue, 16 Feb 2021 09:35:31 GMT

RE: Watchdog Timer Implementation

Charan — Tue, 16 Feb 2021 06:07:51 GMT

Thanks Jorgen for your answer

I just have a follow up question. Although right now it's not needed for my project but if it's needed, how do I implement a system level watchdog? Should I use app_timer() and kick the dog or is there any other method?

Regards

RE: Watchdog Timer Implementation

Jørgen Holmefjord — Mon, 15 Feb 2021 16:50:49 GMT

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