Hi David,
The MQX RTOS documentation states the following:
The MQX watchdog component provides a software watchdog for each task. If a single
task starves or runs beyond certain timing constraints, the watchdog provides a way to
detect the problem. Initially, the task starts its watchdog with a specific time value, and if
the task fails to stop or restart the watchdog before that time expires, MQX calls a
processor-unique, application-supplied expiry function that can initiate error recovery.
Before a task can use the watchdog component, the application must explicitly create it
by calling _watchdog_create_component() with the interrupt vector of the periodic
timer device and a pointer to the function that MQX will call, if a watchdog expires.
When first reading this it states “the interrupt vector” implying that you can have multiple watchdog expiry functions (one for each task) associated with BSP_TIMER_INTERRUPT_VECTOR.
But this is not the case, the watchdog component can register only one function to the interrupt vector. The second time it fails because it was initialized already.
_lwsem_wait((LWSEM_STRUCT_PTR)(&kernel_data->COMPONENT_CREATE_LWSEM));
if (kernel_data->KERNEL_COMPONENTS[KERNEL_WATCHDOG] != NULL) {
_lwsem_post((LWSEM_STRUCT_PTR)(&kernel_data->COMPONENT_CREATE_LWSEM));
_KLOGX2(KLOG_watchdog_create_component, MQX_OK);
return(MQX_OK);
} /* Endif */
I am not sure how this would work for multiple tasks with just the one associated timer interrupt vector (BSP_TIMER_INTERRUPT_VECTOR)??
If you have multiple tasks running and they are all "petting" the same watchdog timer, one task could be stuck while others are just fine and refresh the watchdog. As a result, a stuck task will not cause the watchdog to go off.
Any insight would be appreciated.
Thanks,
Brent
