xQueueGenericSend() given assert due to uxItemSize not being 0

Hey

I have run into an issue, which I would like an explanation for, to better understand the Kernel’s working.

I have a project with a couple of task’s, but the issue lies with 2 of them.

The higher priority task enable some interrupts and start waiting for the interrupts to activates it “main” while loop, in this case via xEventGroupSetBitsFromISR();

In the lower priotity task, I create a Mutex/Semaphore, but are stoppend in function “xQueueGenericSend()” where the kernel tries to set the expected state of the mutex.
The Assert I am hitting is:

configASSERT( !( ( pvItemToQueue == NULL ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) ) );

pvItemToQueue is ok, but the uxItemSize is not 0, but a pointer value ( at least that’s my guess ).

When debugging the code I found that the “xEventGroupSetBitsFromISR()” placed a new item on the same memory place as the uxItemSize for the mutex, which is okay as long as the item are removed before the allocation of the mutex.
But it seems the “xEventGroupSetBitsFromISR()” can get access to the memory as the mutex are getting created.

In my head, when I create a Semaphore and/or Mutex, I should enter a critical area, where interrupts should not be allowed access to the memory, before after the Semaphore or mutex have been allocated, to avoid these issues. But clearly I was wrong in that belief.

To fix my issue for now I have moved the Mutex creation a head of the IRQ enabling, which have fixed the issue completely.

But is my assumption correct, and should I in the future alwasy create my semaphores and mutex before the scheduler even start or what should due?

best regard
Anders

You’ve to ensure that all FreeRTOS resources like semaphores, queues etc. and maybe even tasks are created before they can be (accidentally) used by an ISR.
So yes, it’s good and robust design to enable interrupts after all required resources are created.