Queue Behaviour that I Don't Quite Follow...?

Kernel
#1

groger57 wrote on Thursday, July 14, 2016:

Hello:

I’ve created a queue send and receive function near-identical as per the example in the newest FreeRTOS guide, from page 157.

The only difference being that I have a structure defined and that’s what I am passing in. The structure is 34 bytes, and I havea queue size of 5.
When I send a structure pointer to xQueueSendToBack, the function xQueueReceive gets the pointer and structure correctly, as the debugger shows the contents.

Also in the program, I have a function I use to send data out the UART. After formatting a string, I call the function:
USART_GetResponseStr( scrnBfr );
From the task that performs xQueueSendToBack, I can call this function with a formatted string and the function performs as expected, I get a graphic item on the target screen. However, when I use the same function call from xQueueReceive, (upon pdPASS TRUE) the function appears to break, and nothing gets to the screen.

uint16_t USART_GetResponseStr( char *s )
{
uint16_t getData = 0x0;

//send string out
OutString( s );

while(1) // poll response
{
    getData = USART_FetchChar();    
     if( getData == 0x3E )
    {
        //one more for 0xD
        getData = USART_FetchChar();    
         break;
    }      
 }

return getData;

}

By printing out the formatting string in xQueueReceive, it’s identical to the same call in the task xQueueSendToBack. Can someone please provide some insight as to why this might happen? The only thing I could think of is the task size, it’s set at 200. Adjusting it up made no differnce.

Thanks for any help you can provide!
Gary

#2

rtel wrote on Thursday, July 14, 2016:

The code you posted doesn’t show your use of the queue, but some notes:

  1. Which architecture are you using? (which chip?)

  2. Do you have stack overflow checking switch on?
    (configCHECK_FOR_STACK_OVERFLOW set to 2?)
    http://www.freertos.org/Stacks-and-stack-overflow-checking.html

  3. Do you have configASSERT defined?
    http://www.freertos.org/a00110.html#configASSERT

#3

groger57 wrote on Thursday, July 14, 2016:

Hi,
Sorry for not providing that info. Also, using FreeRTOS 8.2.0

1 - The target is an STM32F4 (cortex M4)
2 - configCHECK_FOR_STACK_OVERFLOW is set to 2
3 - It is defined. in FreeRTOSConfig.h

As mentioned, my use of the queue, if I understand correctly, is the same as the example in the manual, with the exception of the structure. I can post it here if needed.

What might I try next to debug it…a bit lost… thanks.

Gary

#4

groger57 wrote on Thursday, July 14, 2016:

Hi,

For clarity, I am posting the queue related code here:

.#define QUEUE_LENGTH 3

//pxMessage has been malloc’d before here…
uint16_t QUEUE_ITEM_SIZE = sizeof( *pxMessage ); // == 34 bytes

static void prvTimeStampFunction( void *pvParameters );
static void QueueTxScreenFunction( void *pvParameters );

main()
{
QueueHandle_t xQueue;

xQueue = xQueueCreate( QUEUE_LENGTH, QUEUE_ITEM_SIZE );
xTaskCreate(QueueTxScreenFunction, "Tisk", 120, (void*)xQueue, 2, NULL);    

/* Create time stamp task. queue receive and process */
xTaskCreate( prvTimeStampFunction, "Task", 200, (void*)xQueue, 2, NULL );                

vTaskStartScheduler();             

while(1)
{
}

}

static void prvTimeStampFunction( void *pvParameters )
{
QueueHandle_t xQueue;
TickType_t xLastCheckTime = xTaskGetTickCount();

xQueue = (QueueHandle_t) pvParameters;    

for(;;)
{
    vTaskDelayUntil( &xLastCheckTime, 1000 );
    secCtr++;
    
        if( 0 == secCtr%5 )
        {
            //battlink1 is a malloc'd heap instance of the structure
            battLink1->currState = LED_RED;
            xQueueSendToBack( xQueue, battLink1, 10);
        }
}

}

void QueueTxScreenFunction( void *pvParameters )
{
QueueHandle_t xQueue = (QueueHandle_t) pvParameters;
sOBJ *pxMessage;

  for(;;)
{
    if( xQueueReceive  ( xQueue, pxMessage, portMAX_DELAY) == pdPASS)
    {
        sprintf(scrnBfr, "xi %i %i %i\r", pxMessage->currState, pxMessage->xLoc, pxMessage->yLoc);
        printf("got message, here's what queue is sending: %s\n", scrnBfr  );
        /* DOES NOT EXECUTE THIS */
        USART_GetResponseStr( scrnBfr);
    }
    else
    {
        //whatever else there is to do when something breaks...
    }    
}

}

#5

davedoors wrote on Friday, July 15, 2016:

The second parameter to xQueueReceive needs to be a pointer to a buffer that is at least 34 bytes big. You are passing an sOBJ variable. What is sOBJ? If it is a pointer it needs to point somewhere, if it is not a pointer then you need to pass &pxMessage to xQueueReceive.

#6

groger57 wrote on Monday, July 18, 2016:

It is a pointer.
sOBJ is a structure, and I MALLOC from the heap, like this: battLink1 = malloc( sizeof(sOBJ) );
What comes back after mallloc is a pointer, so why would you want to pass it by reference with an “&” ? In my code, I simple created pxMessage as an allocated instance of sOBJ. So is there a problem with that? According to documentation, I don’t see one.

In any case,I have found out what the problem is. After breakpointing the code and stepping into it, I put a printf on the return data in the call to the UART send. After doing that, it started to work. Something bizzare with timing going on when using this perfectly good working function. Insteadf of printf’g something, I just used a junk buffer of 2 byes and sprintf’d a hex char into it. It seems to waste enough time to allow the function to work.

If I don’t use FreeRTOS to pass around structure pointers as in this case of Queues, that code works perfectly fine and has for a few weeks.

Any suggestion as to why using a queue might cause the call to the UART send to behave this way? As below…

uint16_t USART_GetResponseStr( char *s )
{
uint16_t getData = 0x0;
char junk[2];

//send string out
OutString( s );

while(1) // poll response
{
    getData = USART_FetchChar();

** //must put this here, otherwise does not work with FreeRTOS
//can be any value, as long as printf or sprintf is executed**
sprintf(junk, “%x”, 0xF);

    if( getData == 0x3E )
    {
        //one more for 0xD
        getData = USART_FetchChar();    
        break;
    }      
}

return getData;

}

#7

davedoors wrote on Monday, July 18, 2016:

Does USART_FetchChar() just read a register, or do anything else as well? If it disables interrupts and you call it rapidly in a loop I suppose it could be an issue.

#8

groger57 wrote on Monday, July 18, 2016:

More info…
I changed the call to the queue from this:
xQueueSendToBack( xQueue, pxMessage, 10);

To this:
xQueueSendToBack( xQueue, TempMTR, portMAX_DELAY);

And added this after each call to xQueueSendToBack:
vTaskDelay(10);

And removed the sprintf in the UART function, it’s clear a delay was needed and that’s all it was doing.

Question is, why do I need a delay when the call to xQueueSendToBack uses “portMAX_DELAY” ?
Doesn’t that imply it will block until the message is popped from the queue?

Thanks again,
Gary