mbedded wrote on Thursday, November 09, 2017:

Is there recommended way to have all or most tasks inhibit the watchdog kick ?
So if anyone task hangs, the watchdog will reset the system

richard_damon wrote on Thursday, November 09, 2017:

What I typically do is have every task that should be executing periodically set a different bit in a word (guard the setting with a critical section), and a low priority (maybe even in the idlehook) check the word for all the bits set, and if so clear them and kick the watchdog. If any task doesn’t run, or something hogs the processor, the watchdog will reset the system.

Not every task in the system will get a bit, as some tasks might not be expected to run periodically, but you can also add a check that there isn’t a pending request for those tasks.

rtel wrote on Friday, November 10, 2017:

Taking Richard D’s suggestion further - most of the important tasks in
the FreeRTOS demos increment a counter, then a central ‘check’ task
ensures that all the expected counters are counting at the expected
state before kicking the dog.

mbedded wrote on Friday, November 10, 2017:

Thanks and appriciated.

ayazar wrote on Friday, November 10, 2017:

I think this could be an alternative: The monitor task has the highest priority and tasks that are expected to run periodically send an event or put a message in a “monitor queue” in each period. Then the monitor task periodically (possibly with a wider period) check messages. If a task fails, it can even restart it using task API functions or inform the user or logs it.

This approach may have an advantage over Richard’s suggestion because when monitor task has the lowest priority (like idlehook), it can’t run if another task is stuck in while() loop due to scheduler algorithm. The only way to reset processor is hardware watchdog as Richard’s mentioned. But this may not be informative for developer.

The best way may be a monitor task with the highest priority + watchdog timer reset in case of scheduler crash due to coding error.


richard_damon wrote on Friday, November 10, 2017:

I would rarely find the highest priority proper for the watchdog task. I often have a couple of operations with very tight time budgets that need to be made topmost priorities, and making them compete with the watchdog task, which does NOT have that sort of tight time line. Placing it below the very time critical tasks but above the tasks with human scale timing, does give you the ability to try to detect the problem and report it before the watchdog resets you, but then I would want to add a chek that the idle hook does get some time to catch the case that some low priority task that maybe can’t be directly monitored, because it isn’t regularly active doesn’t lock up the system.