FreeRTOS assertion error.

[fly135]

I know this is not ESP32 specific and I looked online to see if I could find any info. But I was hoping that someone here might have an idea. My application failed an assertion in the tasks.c xTaskNotify function (line 4887)

Code: Select all

				/* The task should not have been on an event list. */
				configASSERT( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) == NULL );

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?

John A

[fly135]

Just to update anyone who is interested.... I posted on the freertos forum and this assertion happens when you are waiting for and get a task notification, but you are also waiting on an event (or so it appears). Since it's not possible (or so it seems) to be waiting for notification and waiting on an event at the same it could be corruption of the data in the TCB (Task Control Block).

John A

[ESP_Dazz]

I've got a hunch this maybe an SMP problem. Could you provide more details with what your application was doing such as...
- What tasks/interrupts were waiting for / giving the task notification?
- What were the priorities and affinities of those tasks?
- Were those tasks also accessing queues as well?

[fly135]

I've got a hunch this maybe an SMP problem. Could you provide more details with what your application was doing such as...
- What tasks/interrupts were waiting for / giving the task notification?
- What were the priorities and affinities of those tasks?
- Were those tasks also accessing queues as well?

I'll do the best I can. The task waiting for notification is at priority 7, which is higher than most any task performing the xNotifyGive. I have an event dispatch scheme that is executed on the calling task. So for instance a light measuring task sends an event with the light measurement to all the modules that install a callback. The the task with priority 7 could be getting an xTaskNotify from any number of other tasks. No interrupts are involved.

It's hard to say what any particular priority would be except that's it lower than 7. If by affinity, the "7" task is on core 0, but the tasks calling the xNotifyGive could be assigned to core 0,1, or have no affinity. In this case I forgot which one was the calling task, doh!

No tasks are accessing Freertos queues. I actually use my own queue code. However that queue code does use the xSemaphore API for thread synchronization.

John A

[Gardin]

I'm facing the same issue. What is funny is that I'm not waiting for any event on the receiving task... So it must be something with the sender task perhaps?

Currently usin esp-idf version: v4.1-dev-2055-gf5b82c5b1-dirty

I wanted to use task notifications as a simple queue, since I only need to pass one uint32 value... But maybe I'll have to go with the traditional queues.

--

Gardin.