Watchdog concept with xTaskNotifyWait(), xQueueReceive(), xSemaphoreTake() etc

Kernel
1

Hi everyone,

I’m implementing a hardware-watchdog functionality on my LPC4078 with freeRTOS V8.2.0. I read many forum entries and searched on google for the best concept. Therefore I created a monitoring task which checks if all observed tasks did set their “I’m still running” - flag in a global variable.
These tasks have a lot of xTaskNotifyWait(), xQueueReceive() and xSemaphoreTake() - calls. Most of them get the parameter “xTicksToWait” as portMAX_DELAY (=0xFFFFFFFF) and maybe will wait for a long time.

How to deal with this in the watchdog concept?
Should I write while-loop around this functions with xTicksToWait=1000ms and trigger watchdog inside these loops?
Or is there a built-in possibility to trigger watchdog in the background inside these waiting functions?
Or is there a way to check clearly that the tasks is waiting in such a function and then skip watchdog check for this task? E.g. in blocked state? Or could block state have a any other meaning? And what if task is with 99,9% propability in blocked state and only for a very short time in running/ready so it would be nearly everytime be ignored (=senseless)?

Would be great if you have some good ideas how to deal with that - thank you!

Regards,
Daniel

2

hi,I used to got ideal as you mention, and found ,a portMAXDELAY problem like you said.now maybe you can just put the kicking opration in the Idlehook

3

Why should I put the kicking operation in idlehook (I don’t want to check idle hook)? What if several tasks are in a blocked state?
My question is how can I detect if a task is waiting in one of the mentioned functions and should be ignored for watchdog mechanism?
Or are there other possibilities like a while loop around of every of these functions and limit xTicksToWait to e.g. 1000ms?

4

One comment, having just an Ad-Hoc watchdog routine doesn’t normally add much to a program, it often ends up just checking that the system hasn’t totally hung, and if it does it resets the system so you can’t find out where the system hung.

To make a proper watchdog system, you need to look at each critical sub-system and decide what they HAVE to be able to do every watchdog period and check that this has been done. Yes, you may have some things like a command processor which may have periods with nothing to do, and for those rather than having an infinite wait for an action, you change it to a finite wait after which you report that you are still active.

5

Yes I’m checking all tasks prior whether they should be observed by watchdog or not. And those who should, may contain waiting routines I mentioned.
@richard: Would your proposal be to change infinite loops to finite? But in the procedure it’s not suitable to continue after a short time.
Isn’t there any elegant way for watchdog kicking with the mentioned functions?

6

If the task would be in an infinite wait for something to do, and waiting like that for a long time, but you want to be able to check that the task doesn’t get stuck actually doing something, then drop the timeout to below your watchdog time, and check the results of the wait. If it timed out, then you just mark to the watchdog that you are still ‘good’, and go back to the wait.

7

Okay, for me this would be something like this:

do {
    ret = xTaskNotifyWait(0, 0, &ulNotifiedValue, 1000);
    kickWatchdog();
} while (ret != pdPASS);

Would you agree?

8

That would be one way to do it, I am assuming that kickWatchdog() does what is needed to signal that THIS task is running (unless this is the only task that need to be checked).

9

A watchdog system is far beyond writing into a register on a regular basis. You need to be more specific into your intentions, but meanwhile I want to add up to the conversation sharing this great post:

I also found a very interesting use of WD (eg. you need to check ALL your tasks before you kick the dog), but it was inside a book that I don’t already have its name, nor I can share it, anyway.

EDIT: I found this other great article: