Hello
Under a stress test after about 10 min my programm fails in attempt to give semaphore
test = 1;
SemaphoreHandle_t x = xSemaphoreGive (gp_SenderInCountingSem);
if (!x)
{
OS_PL_ASSERT(0);
}
test = 0;
xSemaphoreGive does not return 0, but gets stusk inside configASSERT IN this code in the xTaskRemoveFromEventList function:
BaseType_t xTaskRemoveFromEventList( const List_t * const pxEventList )
{
TCB_t *pxUnblockedTCB;
BaseType_t 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 !
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).
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.
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: RTOS for ARM Cortex-M
If you are using one of the latest versions of FreeRTOS then the
additional assert messages will find most misconfiguration issues but
not all.
Would you please describe your problem in a bit more detail? Are you also seeing as assert on the exact same line? Which hardware platform are you using? Have you tried all the steps mentioned here: https://www.freertos.org/FAQHelp.html