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

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?

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

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 );

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

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)

Thanks, I’ll look into that. I edited my last message when I fully grasped what you were saying.