Dear All,
I was wondering if you could provide any examples or advice as to good practice techniques when using the Watchdog timer in a multi-threaded Zephyr application.
Dear All,
I was wondering if you could provide any examples or advice as to good practice techniques when using the Watchdog timer in a multi-threaded Zephyr application.
Just adding few points on top of Kenneth's info.
Regarding practice, the concept still is the same in the multi-threaded application. What I mean is that RTOS based or baremetal, the WDT is normally considered when there are few execution contexts in your application that are expected to run within given timeouts to be able to obey the real-time constraints of your system or to come out of some deadlocks. The key here is to set correct priority levels to these execution contexts (or detect the correct execution contexts if priorities are set in the architecture already) from where you feed the watchdog.
In baremetal (no RTOS) there are normally fewer contexts (ISRs and main thread). These are mostly ARM->NVIC based priorities that you need to detect/architect from where you feed the watchdog.
In RTOS based application you also add RTOS based threads as execution contexts on top of the above mentioned contexts. You need to pick few execution contexts (threads in RTOS) where you believe that those threads cannot be let starve for certain amount of time. These times are normally what you give as timeout as wdt configuration. If you have more than one such execution context (like Kenneth mentioned, you can have 8 in nRF), then you choose the wdt as the largest allowed time (worst time delay) among those threads as the wdt timeout. Hope this helps
Just adding few points on top of Kenneth's info.
Regarding practice, the concept still is the same in the multi-threaded application. What I mean is that RTOS based or baremetal, the WDT is normally considered when there are few execution contexts in your application that are expected to run within given timeouts to be able to obey the real-time constraints of your system or to come out of some deadlocks. The key here is to set correct priority levels to these execution contexts (or detect the correct execution contexts if priorities are set in the architecture already) from where you feed the watchdog.
In baremetal (no RTOS) there are normally fewer contexts (ISRs and main thread). These are mostly ARM->NVIC based priorities that you need to detect/architect from where you feed the watchdog.
In RTOS based application you also add RTOS based threads as execution contexts on top of the above mentioned contexts. You need to pick few execution contexts (threads in RTOS) where you believe that those threads cannot be let starve for certain amount of time. These times are normally what you give as timeout as wdt configuration. If you have more than one such execution context (like Kenneth mentioned, you can have 8 in nRF), then you choose the wdt as the largest allowed time (worst time delay) among those threads as the wdt timeout. Hope this helps