I have a task which is waiting indefinitely for lightweight task notification
ulTaskNotifyTake( pdTRUE, portMAX_DELAY );
The task is in the suspended state. When I try to abort the delay with
xTaskAbortDelay(
thattask_)
It does not resume running – it stays in the suspended state. Other taks which are waiting indefinitely for an OS object resume running when their delay is aborted.
I tracked this to a point in the OS (tasks.c) where it determines if the task is really suspended or waiting indefinitely
else if( pxStateList == &xSuspendedTaskList )
{
/* The task being queried is referenced from the suspended
list. Is it genuinely suspended or is it block
indefinitely? */
if( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) == NULL )
{
eReturn = eSuspended;
}
else
{
eReturn = eBlocked;
}
}
Tasks waiting indefinitely for an OS object return eBlocked whie the task waiting indefinitely for a lightweight notification return eSuspended, and consequently fail this check
/* A task can only be prematurely removed from the Blocked state if
it is actually in the Blocked state. */
if( eTaskGetState( xTask ) == eBlocked )
{
I encountered this with FreeRTOS 9.0.0 so I tried 10.0.1 but it behaves the same.
The MCU is an NXP Kinetis K24. The compiler is IAR 8.22.1 with low optimization.
Is this how it is supposed to work or is this a bug?
Thanks,
Matt