xTaskNotify assertion

Kernel
1

fly135 wrote on Monday, July 30, 2018:

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

2

rtel wrote on Monday, July 30, 2018:

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?

3

fly135 wrote on Monday, July 30, 2018:

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

4

rtel wrote on Monday, July 30, 2018:

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

fly135 wrote on Tuesday, July 31, 2018:

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

6

rtel wrote on Tuesday, July 31, 2018:

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

7

fly135 wrote on Tuesday, July 31, 2018:

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