I am using latest FreeRTOS version 7.5.2, and having crash in XqueueGenericsendfromisr, my software is pretty complex and include TCIP stack from Microchip, I have few task but the problem is located in Uart1 ISR, my code is derivated fromdemo as follow :
I discovered the hang is when calling xQueugenericSendFrom ISR, putting some “Led on” trace, I was able to discover the problem was when calling prvCopyDataToQueue (from xqueuegeneric) and exactly on this line :
( void ) memcpy( ( void * ) pxQueue->pcWriteTo, pvItemToQueue, ( size_t ) pxQueue->uxItemSize ); /*lint !e961 !e418 MISRA exception as the casts are only redundant for some ports, plus previous logic ensures a null pointer can only be passed to memcpy() if the copy size is 0. */
I do not see why this memcpy give me hang, but I just saw that few other people on other platform are having pb on xqueuesend or xqueuereceive call.
…I should have said why I’m asking this, there is another thread on a completely different MCU that has a problem with sending to a queue from an ISR. I have asked for the code so I can investigate.
I made some progress and discover the memcpy failed due to ( size_t ) pxQueue->uxItemSize is equal to 0, tracing the uxitemsize when entering in xQueueGenericSendFromISR is also 0, there is no reason this is 0 since my initialization of queue works good as this :
Technically memcpy’ing zero bytes is undefined behavior, but I have never seen it do anything other than just return from the function. FreeRTOS actually relies on that for semaphore behavior. Whatever happens, it should not crash.
This sounds like a simple data corruption. At some point the queue structure is being clobbered. Can you put a data watchpoint on where ever pxQueue->uxItemSize is in RAM so your debugger will break when it gets written over.
I just discovered that length of pxqueu is also corrupted so probably the whole structure, as we pass an handle to xQueueGenericSendFromISR, I was wondering is there is something wrong in this line :
You should not be using xQUEUE structures at all, and indeed you should not have access to the data type outside of the queue.c file, which is an internal file that should not be edited.
Have you modified code in queue.c or added code to queue.c?
Other than that, it does just sound like data is being corrupted. You will have to catch whatever is writing over the RAM that is holding the queue structure. If your debugger cannot do that with a data watchpoint, as already suggested, you will have to do it manually.