Watchdog refresh for system with variable number of tasks

Kernel
1

Hi all,

My system running under FreeRTOS 9.0.0 has three default running tasks: a control task, an interface task and a display task. If the user enables a modbus function, a modbus task is created by the control task, at the same time, when the user disables the modbus interface, the modbus task is deleted and its handle erased.

This raise the question on how to manage the watchdog refresh if tasks are 3 or 4.

This is my approach:

  • At startup an Event Group “WDG_eventgroup” is created
  • EventBits_t xEventGroupValue is allocated as global
  • Each task sets its own bit in xEventGroupSetBits at the end of the task loop, the bit is allocated also for the modbus task.
  • In the highest priority task the watchdog is refreshed if all other tasks checked in, the check to determine if task to monitor are 3 or 4 is if the modbus task handle is NULL.
    BASIC_TASKS_BITS is a define with the bits of the three always present tasks ORed together.

In the highest priority task, at the end of the loop:

	if (modbusTaskHandle == NULL)
	{
		xEventGroupValue =xEventGroupWaitBits(WDT_group, BASIC_TASKS_BITS, pdTRUE, pdTRUE, 0);
		if ((xEventGroupValue & (BASIC_TASKS_BITS)) == (BASIC_TASKS_BITS))
		{
			KickTheDog();
		}
	}
	else
	{
		xEventGroupValue = xEventGroupWaitBits(WDT_group, BASIC_TASKS_BITS | MOD_MASTER_TASK_BIT, pdTRUE, pdTRUE, 0);
		if ((xEventGroupValue & (BASIC_TASKS_BITS | MOD_MASTER_TASK_BIT)) == (BASIC_TASKS_BITS | MOD_MASTER_TASK_BIT))
		{
			KickTheDog();
		}		
	}

Just to know if this is a right practice and/or how it could be improved.
Thanks

Regards
Daniele

2

The question seems to be ‘how to determine the number of tasks running in system’.

One approach:
If tasks won’t be deleted at runtime, and determining which task failed is not a requirement – uxTaskGetNumberOfTasks() API could be an alternative solution. (Could subtract 2, if both are IDLE task and timer task are enabled and you don’t intend to check them with watchdog. Or could -1 and put watchdog logic in IDlE hook function…) https://www.freertos.org/a00021.html#usTaskGetNumberOfTasks

Another approach:
If you have some memory to waste, uxTaskGetSystemState() gives more information about tasks. (e.g. if allow deleting tasks, could use this API to filter out tasks deleted but not yet freed by the idle task. These tasks are not subject to watchdog rule. Not sure if this API is in v9.0.0.) https://www.freertos.org/uxTaskGetSystemState.html

Above sounds generic, but not necessarily better. Depending on the scenario.

1 Like
3

First question is do you really need to delete and recreate the modes task, or can it just block waiting for it to be needed. That could simplify your logic.

Second, Everyone just poking an event in the event group each loop isn’t a great watchdog test. I tend to make the watchdog task relatively LOW priority, higher than any background non-critical task, but low enough that if some task starts to starve the system of CPU time, it will also starve the dog. Normally keeping up with the watchdog isn’t a time critical task with tight deadlines, so it getting delayed by higher priority tasks shouldn’t be a problem. It taking time at a critical moment from a true high priority task can be.

When I am running a watchdog, I start from my specs of needed response times, and have each task with such deadlines record how it is doing in a time stamp message in a memory block. The watch dog task can scan these, see if any task hasn’t reported in within ITS requirements (thus some tasks can have response periods longer than the watchdog period) and if all is good, you kick the dog, if not you report the problem. The hardware watchdog is only really needed if the system hangs hard enough that the watchdog task doesn’t get a chance to run in time to make its report.

1 Like