assert in xTaskRemoveFromEventList

Hello Under a stress test after about 10 min my programm fails in attempt to give semaphore ~~~ test = 1; SemaphoreHandlet x = xSemaphoreGive (gpSenderInCountingSem); if (!x) { OSPLASSERT(0); } test = 0; ~~~ xSemaphoreGive does not return 0, but gets stusk inside configASSERT IN this code in the xTaskRemoveFromEventList function: ~~~ BaseTypet xTaskRemoveFromEventList( const Listt * const pxEventList ) { TCBt *pxUnblockedTCB; BaseTypet xReturn;
/* THIS FUNCTION MUST BE CALLED FROM A CRITICAL SECTION.  It can also be
called from a critical section within an ISR. */

/* The event list is sorted in priority order, so the first in the list can
be removed as it is known to be the highest priority.  Remove the TCB from
the delayed list, and add it to the ready list.

If an event is for a queue that is locked then this function will never
get called - the lock count on the queue will get modified instead.  This
means exclusive access to the event list is guaranteed here.

This function assumes that a check has already been made to ensure that
pxEventList is not empty. */
pxUnblockedTCB = ( TCB_t * ) listGET_OWNER_OF_HEAD_ENTRY( pxEventList );
configASSERT( pxUnblockedTCB );
~~~ Is there any idea how to troubleshoot this problem? The FreeRTOS configuration is dynanmic, but I don’t actually use any malloc. The target is STM32F4. I will be gratefull for any advice !

assert in xTaskRemoveFromEventList

First thing to do is look through this list: https://www.freertos.org/FAQHelp.html – starting with the requirements for interrupt priorities on the Cortex-M, and the special requirements to change the number of priority bits assigned to be preemption priority on the STM32 (which is the only part I’m aware of that does not automatically set all priority bits to preemption priority as opposed to sub-priority).

assert in xTaskRemoveFromEventList

Thank you Richard for the prompt answer. Actually, I already checked the interrupt priority and didn’t find any potential issue, but maybe Ishould have looked for something different. Could you please suggest what is some specific issue with priorities I should check? Note again, sometimes my program survives under test (180 000 messages x 2 UART) and a dozen of tasks for 10 –15min . I read your article and tomorrow will increase the stack size of the task in which context the problem happens.

assert in xTaskRemoveFromEventList

Actually, I already checked the interrupt priority and didn’t find any potential issue, but maybe Ishould have looked for something different. Could you please suggest what is some specific issue with priorities I should check?
I can’t say anything more than is already comprehensively documented here: https://www.freertos.org/RTOS-Cortex-M3-M4.html If you are using one of the latest versions of FreeRTOS then the additional assert messages will find most misconfiguration issues but not all.