Data corrupted in queues between ISR and FreeRTOS task

jiricharvat wrote on Monday, June 15, 2015:

I would like to use FreeRTOS queues for sending messages between USB Isr() and Rtos Task. But the queues do not seem to work - at higher speeds/volumes the data seems to be inconsistent or corrupted. Namely assert configASSERT(cmd->m_type == UNDEF_CMD) fails.

Interrupt routine is using GetFreeCommandFromISR() and HandleCommandFromISR():

<a href="#">
struct sCmd\* GetFreeCommandFromISR()
    struct sCmd\* cmd;
    BaseType_t res = xQueueReceiveFromISR( coreFreeCmd, &cmd, NULL );
    configASSERT(res == pdPASS);
    configASSERT(cmd->m_type == UNDEF_CMD);
    return cmd;
//Now the interrupt routine fills data received via USB into sCmd structure and 
//enqueues it into coreQueue for processing in Rtos task
void HandleCommandFromISR(struct sCmd\* c)
    BaseType_t res = xQueueSendToBackFromISR( coreQueue, &c, 0U );
    configASSERT(res == pdPASS);

The RTOS task is using this main loop:
for( ;; )
    /* Wait until something arrives in the queue - this task will block */
    while(pdPASS == xQueueReceive( coreQueue, &cmd, portMAX_DELAY ) )
        /* ProcessCoreTaskCommand */

        BaseType_t res;
        do {
            struct sCmd\* cmd2 = cmd;
            cmd2->m_type = UNDEF_CMD;
            res = xQueueSend( coreFreeCmd, &cmd2, 0U );
        } while(res != pdPASS);

Hardware: SmartFusion2 StarterKit, SoftConsoleIDE 3.4
FreeRTOS: 8.2.1 (having the same with 8.1.2)
I have a full demo of this using FreeRTOSV8.2.1\FreeRTOS\Demo\CORTEX_SmartFusion2_M2S050_SoftConsole (is it possible to attach it to the forum?)
Because of the issue I am considering to use the new Task notifications instead.
Thanks for any comment.

richard_damon wrote on Monday, June 15, 2015:

Queue are not best for high volume as they copy the data into and out of the queue, but that shouldn’t cause corruption. I think that the code show is a bit corrupted as the code seems written as if cmd is a pointer to a struct sCmd, but the code reads as a struct sCmd.

I do note that in GetFreeCommandFromISR has the asserts backwards, if the QueueReceive fails then you first test for the cmd being right before checking that you GOT a cmd. The issue could well be that you are running out of buffers.

I note that you aren’t using a “higher task was woken” flag in your queue operations, which says that likely your ISR isn’t triggering the scheduler, which says that the receive task won’t wake up until the next timer tick, which might cause buffer exhaustion issues at higher data rates.

jiricharvat wrote on Tuesday, June 16, 2015:

Thanks a lot for the comments
>> the code seems written as if cmd is a pointer to a struct sCmd, but the code reads as a struct sCmd
…The star * was missing in the displayed code, so it is now corrected. The queues are copying only pointers to sCmd (the sCmd has a buffer of 512 bytes internally).

>> GetFreeCommandFromISR has the asserts backwards
Ok, thanks. In actual code there was first assert for res == pdPASS, and then cmd->m_type == UNDEF_CMD. Again corrected in sample above.

>> “higher task was woken”
Great, I will learn how to use it.

Most likely I will have to dig inside the queues with debugger or printouts to understand what is going on… But first I will try to use the Task notifications instead to have something working.