xTaskNotify assertion
My application failed an assertion in the tasks.c xTaskNotify function. I’m calling xTaskNotify with the handle of the task. Now my app has been calling this function since it booted maybe 20 hours ago. I just happened to notice it has rebooted as a result of the assertion. The only clue is the comment….
“The task should not have been on an event list”
Anyone know what this means?
~~~
/* The task should not have been on an event list. */
configASSERT( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) == NULL );
~~~
John A
xTaskNotify assertion
A task can be blocked on a task notification, or an RTOS object such as
a queue, semaphore, stream buffer, event group etc. …. but it can’t be
blocked on both a the same time. The assert has detected an
inconsistent state, because if the xEventListItem is not NULL, then it
would appear that the task was blocked on an RTOS object too (which
would not be possible).
A simple explanation for this would be a simple old data corruption –
maybe the xEventListItem has been overwritten?
xTaskNotify assertion
My task has this statement so that it doesn’t wait when notified….
int ret = ulTaskNotifyTake(pdTRUE, msDelay(200));
But if it times out the task could be doing a lot of other things. So for example if the task is sending and reading data from a socket it might be waiting for a socket related event. So ruling out data corruption for the time being… if the task was waiting on a socket and the xTaskNotify was called (by another task) to signal this one would that potentially cause this assertion?
John A
xTaskNotify assertion
The line with the assertion should not execute unless the task was
waiting for a notification. So if your 200ms block time (from you last
post) has expired, and the task is no longer waiting for the
notification, then the assert should not get hit as that line of code
would never execute, see:
/* If the task is in the blocked state specifically to wait for a notification then unblock it now. */ if( ucOriginalNotifyState == taskWAITING_NOTIFICATION ) { ( void ) uxListRemove( &( pxTCB->xStateListItem ) ); prvAddTaskToReadyList( pxTCB ); /* The task should not have been on an event list. */ configASSERT( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) == NULL );
xTaskNotify assertion
Thanks for that explanation. So that means maybe I should consider data corruption.
edit: So for some reason it appears that my task was waiting for some event at the same time it was waiting for notification.
Thank you for your help.
John A
xTaskNotify assertion
I’m afraid I’m not familiar with the way Espressif have integrated lwIP
– but it is the case that if you have nested functions that unknowingly
(so unmanaged) both use task notifications for different purposes you
can get into a twist – however I don’t think even that would explain
what you are reporting for the reason as per my previous email.
Try setting configUSELISTDATAINTEGRITYCHECK_BYTES to 1 in
FreeRTOSConfig.h – assuming you have configASSERT() defined then that
can help confirm a data corruption, although it unfortunately can’t
prove there isn’t one.
(actually, I know you have configASSERT() defined, as that is how this
thread started ;o)
xTaskNotify assertion
Thanks, I’ll look into that. I edited my last message when I fully grasped what you were saying.