Failing null pointer assert in xQueueGenericSend

Kernel
1

Running FreeRTOS Kernel V10.4.1 with CMSIS interfaces.

We have added a mutex to our I2C driver wrapper in order to avoid concurrent access to the peripheral. prvProcessExpiredTimer in timers.c is calling a our registered timer callback, which eventually grabs the mutex to send some I2C traffic.

I am seeing an assert give → xQueueGenericSend() where it checks for a NULL pointer (line 777):

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

Given that the function accessing the mutex was able to Get it, I am not sure how this is happening. Any thoughts on what we could be doing wrong?

void uC_I2C_MasterTx(mxc_i2c_regs_t * p_I2C, uint8_t slave_addr, uint8_t * p_tx_data, uint8_t num_bytes)
{
    i2c_flag = 1;

	osMutexWait(UC_I2C_Mutex_ID, osWaitForever);
    if(I2C_MasterWrite(p_I2C, slave_addr, p_tx_data, num_bytes, 0) != num_bytes)
    {
    	RTE_LOG(RTE_LOG_CATEGORY_ERR, EVENT_ID_I2C_TX_FAIL, 
        RTE_GetSlaveNameFromAddress(slave_addr));
    }
	osMutexRelease(UC_I2C_Mutex_ID);
}

Here is the call stack:

image

2

How/where is UC_I2C_Mutex_ID declared and defined and when is it initialized ?
Should be a global variable declared extern and initialized before accessing it.
Did you verify that the queue was properly created returning a valid handle ?

3

It is is created and initialized using the CMSIS calls.

osMutexDef (UC_I2C_Mutex);    // Declare mutex
osMutexId  (UC_I2C_Mutex_ID); // Mutex ID

…

void uC_I2C_Init(void)
{
	UC_I2C_Mutex_ID = osMutexCreate(osMutex(UC_I2C_Mutex));

    if (UC_I2C_Mutex_ID == NULL)
    {
        RTE_LOG(RTE_LOG_CATEGORY_ERR, EVENT_ID_OS_RESOURCE);
    }

It’s successfully created. I don’t think this is an initialization issue since the test above passes and the code runs for quite some time, using I2C, before hitting this. Maybe a system stack issue?

4

I agree. If the code is working for a certain time I also think there might be memory corruption. Very often the reason for that is a stack overflow.
So did you already enable stack checking ?