Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Problem with xQueueSend/Receive in long run..

Posted by Vagner on October 2, 2009
Hi, there.

I'm experiencing some strange behavior while using xQueueSendFromISR and xQueueReceiveFromISR in a kind of long running process.

Being practical, let the array of bytes [16, 2, 102, 2, 0, 16, 3] be a sample data among thousand others. Then an excerpt of an ISR could be:

while (U1STAbits.URXDA)
{
cChar = U1RXREG;
xQueueSendFromISR(UART1RxQueue, &cChar, &xHigherPriorityTaskWoken);
}

Now supposing another sample data like [ 76, 1, 21, 29, 80] was received via UART and then enqueued, in another task like this

for (;;)
if (xQueueReceiveFromISR(com1RxQueue, &cChar,
&xHigherPriorityTaskWoken) == pdTRUE)
// do something

one would expect getting the same sequence of bytes, but I just got [3, 76, 1, 21, 29] instead - note the last byte of the first sample array is at the first index of its subsequent sample array.

It seems there's a byte to be consumed at the queue, but the queue itself just doesn't know about it. I think that "suspicious" byte was not lost, it just got stuck somewhere between xQueueSend and xQueueReceive.

Does anyone could help me, please? Thanks in advance.

Best,

Vagner

RE: Problem with xQueueSend/Receive in long run..

Posted by Richard Damon on October 3, 2009
My first question is did the full first message get removed from the queue when the previous message was fetched, and how does it know when one message ends and the next starts.

I note that your second example you call it a "task", but use the "FromISR" version. Tasks should use the version without FromISR, if this is actually in an ISR that is ok.

Lastly, remember that data from a Serial Port (which U1RXREG sounds like) does not all arrive at once. Even if you use a fifo, then it may fill enough to trip an interrupt before all of a packet has arrived, so just reading out until the queue is empty and then calling that the end of a packet isn't reliable unless you do something else to make sure the whole message has been received.

RE: Problem with xQueueSend/Receive in long run..

Posted by Vagner on October 5, 2009
Hi, Richard. Thanks for your reply.

Here your are some additional notes:

1) My queue is only 1 byte length, so I'm sure a full first message was removed from the queue before a second one got put there.

2) I have a state machine working against a DLE/STX/DLE/ETX -like protocol (wich does perform CRC validation), so I'm able to know when each message starts and ends.

3) My fault about the "FromISR" inside a task. Anyway, whatever xQueueReceive ("FromISR" or not) I may use, results are the same.

4) It's important to say this behavior only appears after several minutes of hard working. After only a few minutes, this problem doesn't come up.

Hope I've provided you clear information. Thanks again.

Best regards,

Vagner

RE: Problem with xQueueSend/Receive in long run..

Posted by Vagner on October 20, 2009
Hi again.

I've just replaced xQueueSendFromISR() and xQueueReceive() with a pretty simple queue I've created manually (see bellow) and it's been working fine now.

void testQueueSend(signed portCHAR * data)
{
if (p == 20)
p = 0;

buffer[p++] = (signed portCHAR) *data;
return;
}

and

char testQueueReceive(signed portCHAR * data)
{
if (c == 20)
c = 0;

if (buffer[c] != -1)
{
*data = buffer[c];
buffer[c++] = -1;
return 1;
}

return 0;
}

So, could it be a bug? (This doesn't happen at low baud rates.)

Best.

RE: Problem with xQueueSend/Receive in long run..

Posted by MEdwards on October 22, 2009
Are you using a port that supports interrupt nesting? If so is your interrupt running at or below configMAX_SYSCALL_INTERRUPT_PRIORITY?


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists