Dear All, 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 :

IFS0bits.U1RXIF = serCLEAR_FLAG;
    U1STAbits.OERR = 0; 
while( U1STAbits.URXDA )
{
    cChar = U1RXREG;

            xQueueGenericSendFromISR( xUart1RxedChars, &cChar, &xHigherPriorityTaskWoken, queueSEND_TO_BACK );

// xQueueSendFromISR( xUart1RxedChars, &cChar, &xHigherPriorityTaskWoken ); // PORTDbits.RD2 =1; }

if( xHigherPriorityTaskWoken != pdFALSE )
{
    taskYIELD();
}

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. Any idea welcome. Regards

Can you say for definite that this only happens with V7.5.x code, and using the exact same project with V7.4.x it does not happen? Regards.

…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. Regards.

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 : xUart1RxedChars = xQueueCreate( uxQueueLength, ( unsigned portBASE_TYPE ) sizeof( signed char ) ); if this info can help ?? regards

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.

Dear, I was not able to trace where the size is corrupted, so at that time I am just lock in my project, hope to have some idea during the day. Regards

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 : xQUEUE * const pxQueue = ( xQUEUE * ) xQueue; ?? Regards

Dear Richard, Any idea where I can investigate ?, for information I use Heap2 strategy for memory management. Thanks & Regards

xQUEUE * const pxQueue = ( xQUEUE * ) xQueue;

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. Regards.

I did not modify queue.c except to put some trace, I will continue to search. Regards