Possible reasons for xSemaphoreCreateMutex() to fail

variable · August 4, 2020, 2:01pm

I’m running on FreeRTOS Kernel V10.0.1 - the NXP Port for the RT1052 -

Using code based on their power_mode_switch_ca demo, in my implementation, on startup (before the task scheduler is started), xSemaphoreCreateMutex() is called and usually works just fine, but intermittently it fails configAssert( pxQueue) in xQueueGenericSend()

BaseType_t xQueueGenericSend( QueueHandle_t xQueue, const void * const pvItemToQueue, TickType_t xTicksToWait, const BaseType_t xCopyPosition )
{
BaseType_t xEntryTimeSet = pdFALSE, xYieldRequired;
TimeOut_t xTimeOut;
Queue_t * const pxQueue = xQueue;

	configASSERT( pxQueue );  // <---- fails here occasionally for some reason

What reasons could cause xSemaphoreCreateMutex to possibly fail before the scheduler is even started?

rtel · August 4, 2020, 2:26pm

The assert shows the mutex handle is null. Do you check the mutex is created before trying to use it? If it is created, and then the assert fails, something else must be writing over the mutex handle, although that seems unlikely as it would have to write zero over the handle for that assert to fail.

variable · August 4, 2020, 2:33pm

Hi @rtel,
Thanks for the quick response!

The call stack at the assert is:

So asserting when i’m trying to create the Mutex, before anything tries to use it… which is why i’m a little unsure of how to debug & looking for some ideas.

hs2 · August 4, 2020, 2:51pm

Seems you‘re doing a couple of things in main…
Take care that the main stack size (usually configured in the linker script) is sufficient.
Also avoid using variables defined in main because later on the main stack is re-used as ISR stack for a number of MCUs and those variables might get corrupted.
Another approach would be to move some task related code into a task where you can manage the stack size more flexible and where the stack is dedicated to this task.

aggarg · August 4, 2020, 5:37pm

prvInitialiseMutex has a NULL check and therefore, the assert seems like a memory corruption:

github.com

FreeRTOS/FreeRTOS-Kernel/blob/master/queue.c#L492


    #endif /* configUSE_QUEUE_SETS */



    traceQUEUE_CREATE( pxNewQueue );

}

/*-----------------------------------------------------------*/



#if ( configUSE_MUTEXES == 1 )



    static void prvInitialiseMutex( Queue_t * pxNewQueue )

    {

        if( pxNewQueue != NULL )

        {

            /* The queue create function will set all the queue structure members

            * correctly for a generic queue, but this function is creating a

            * mutex.  Overwrite those members that need to be set differently -

            * in particular the information required for priority inheritance. */

            pxNewQueue->u.xSemaphore.xMutexHolder = NULL;

            pxNewQueue->uxQueueType = queueQUEUE_IS_MUTEX;



            /* In case this is a recursive mutex. */

            pxNewQueue->u.xSemaphore.uxRecursiveCallCount = 0;

Would you place a data breakpoint on pxNewQueue after the NULL check in prvInitialiseMutexand see what is setting it to NULL?

Thanks.

variable · August 4, 2020, 6:12pm

thanks @hs2 and @aggarg,
right after seeing @aggarg’s post - i ran thru a few more times to try and hit this assertion and instead of asserting, the next time thru I got the below fault.

While code’s running from flash (via NXP’s XIP mode) - at this point flash is initialized, and the real kicker is the fact that the code works more often than not.
the new queue (pxNewQueue) is stored at location 0x2020_0098 - which is on the device’s internal OCRAM.

I suppose I’ll try @hs2’s idea - run this xSemaphoreCreateMutex from a task instead of main, see if I am able to still replicate.

variable · August 4, 2020, 6:59pm

after moving the xSemaphoreCreateMutex in question to a task - so far unable to get a crash after a few dozen attempts.
Thanks @hs2 and @aggarg!