Watchdog feed while using blocking APIs

[Ankit_chauhan]

Hello,

Currently, I am working on a device that has multiple sensors connected with nRF53. Each sensor collects its own data in its thread. Some sensor threads are related to each other i.e. waiting to get a message from a peer sensor thread via ZBUS to go further measurent.

For example, sensor_thread_1 is waiting to get a message from sensor_thread_2 via a ZBUS channel through zbus_sub_wait_msg API. Once the message is received, the sensor_thread_1 will perform further measurements and then get back to the ZBUS waiting state to receive the next message from sensor_thread_2.

Now, I am implementing a Watchdog in my current project and I need to feed from each loop running continuously (especially the sensor threads). 

So, I need help to handle such a situation where the sensor thread is already blocked by waiting for a ZBUS message or to get Semaphore and feed the watchdog.

[Charlie]

Hi Ankit,

It would be better to have a main thread to run the app logic in a loop.

If you have to use WDT in sensor threads or there is no main loop, you need to pick up a proper watchdog triggering time for it. 

This will depend on your application, as sensor threads may block but only allow them to block for a period of time that your application can tolerate, otherwise the application will reset to restart.

Let me know if you need more advice.

Best regards,

Charlie

[Ankit_chauhan]

Hi Charlie,

Thanks for your reply.

After spending some time finding the solution to this issue, I came across an nRF sample of task_wdt in the nRF SDK sample. I have implemented that into my application using the multi-channel watchdog concept where each channel is configured with common task_wdt_add API. 

On the main thread and a sensor thread, I am using task_wdt_feed which feeds the watchdog with the respective channel ID.

In some instances, I have seen that it is working because if I am not feeding either thread with task_wdt_feed, the task_wdt_callback will be called and the system gets restarted with the channel ID of the thread which is expected.

However, I am unsure how to handle the other sensor threads that have the ZBUS and Semaphore blocking API with this approach.

Regards,

Ankit.

[Charlie]

Hi Ankit,

Thanks for the feedback. May I know which "nRF SDK sample" you refer to? Do you mean Task watchdog — Zephyr Project documentation (nRF Connect SDK) (nordicsemi.com). To be honest, I do not have much experience about Task Watchdog, it is one subsystem originally from Zephyr project. Good to hear it works as you expected, but I need to draw your attention that it used a kernel timer as its backend instead of a separate watchdog peripheral. 

Ankit_chauhan said:

However, I am unsure how to handle the other sensor threads that have the ZBUS and Semaphore blocking API with this approach.

When it comes to this question, have you evaluated what is the maximum time the thread could be blocking? As I shared before, this is critical for picking up the proper watchdog timeout to detect a real loop death, and it is related to your application logic about how to get and process sensor data.

Best regards,

Charlie

[Ankit_chauhan]

Hi Charlie,

Thanks for the update.

Sorry, I was using the Zephyr sample not the nRF SDK sample. Here is the link https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/task_wdt.

For the second query for watchdog control in blocking API, I am thinking of controlling the watchdog start and stop in between the usage of those blocked threads. 

My system is designed like that whenever the sensor sample collection is requested then only I am enabling the sensor threads otherwise all are in a suspended state. So I am planning to enable the task watchdog when the sensor threads are resumed. Similarly will stop the task watchdog when the threads are suspended using the task_wdt_add and task_wdt_delete APIs respectively.

In between these states, even the threads which are having the blocking APIs will run repetitively. As you said I have calculated the time of a thread that stays blocking and I have set that time in the task watchdog time out and that should work.

Let me try this approach and will let you know if I find any issues.

Thanks once again for your support.

Regards,

Ankit.