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

Queue data order change?

Posted by gigglergigger on October 23, 2015

I have a Cortex app with about 15 tasks each with various i/o queues. I've enabled stack checking in config and asserts - no issues.

I have a highest priority task RS485 receiving and sending data to a CAN bus queue. The task that receives this CAN data is lower priority than the sender but the sender is filling the queue slow.

I am seeing data order is changing. All the queues use xQueueSendToBack(...)

sent to CAN queue: 80 ed 11 42 37 54 4c 20 31 38 37 39 36 20 20 20 20 20 20 4a

actually received over CAN bus: 80 ed 42 37 54 4c 20 31 38 37 39 36 20 20 20 20 20 20 4a 11

It seems very consistent. The queue size is larger than 32 CAN frames. There is timing data in the frames that I've missed out, so the above is just some characters.

This is the basic CAN sender task (simplified) and queue.

while(1) {
	// wait here until we get some data to send
	if(xQueueReceive(gxCANData.txQueue[1], &msg, portMAX_DELAY)) {
		xISO11898Send(LPC_CAN2, &msg, eCANTXBLOCK_WAITFREE);
	}
}

The sender in it's simplest form is basically doing:

for(ucI=0;ucI<ucNFrames;ucI++) { xQueueSendToBack(..., frame[ucl], portMAX_DELAY ) }

If I break point in the for(...) loop above, I can see the correct order data.

My CAN analyser shows frames where the squence is out of order.

Strangely I cannot check the queue in the CAN sender task to see if the order there is different. If I breakpoint xQueueReceive(...) I only get 1 entry with first character. However the tasks all still function and send and receive data if I disable the break point to take data from other tasks that are lower or at the same priority. The other tasks using the bus still work sending data. The queue is larger than data being sent in this case and all sends should block waiting for queue space anyway, i.e. send to back with portMAX_DELAY.

Any suggestions?

Regards

dc


Queue data order change?

Posted by heinbali01 on October 24, 2015

data order is changing

The FreeRTOS queues always behave like a FIFO. If it doesn't, then something is wrong. Maybe some memory corruption caused by another task? Maybe the data have been 'reordered' earlier without knowing it? Maybe you missed data from the RS485 bus while doing other things?

Do you still have some RAM left for debugging purposes?

What I would do is add some checking: store all events in a circular buffer along with a time-stamp.

I have a highest priority task RS485 receiving and sending data to a CAN bus queue

Does it ever happen that this priority task task has to wait for space in the queue? If so, could it miss data from the RS485 bus?

I would store every relevant event:

~~~~~ for(ucI=0;ucI<ucNFrames;ucI++) { BaseTypet xResult; xResult = xQueueSendToBack(..., frame[ucl], portMAXDELAY ); vAddEvent( 'S', msg, xResult ); }

BaseTypet xResult; xResult = xQueueReceive(gxCANData.txQueue[1], &msg, portMAXDELAY); if( xResult != pdFALSE ) { vAddEvent( 'R', msg, xResult ); xISO11898Send(LPCCAN2, &msg, eCANTXBLOCKWAITFREE); } ~~~~~

And here is a sketch of such a circular buffer:

~~~~~

define EVENT_COUNT 64

typedef struct { char cFunction; /* In stead of storing the entire messages, you might store a readable string here. */ char pcMsg[ 8 ]; BaseTypet xResult; uint32t ulTime; } Event_t;

Eventt xEvents[ EVENTCOUNT ]; volatile BaseType_t xEventIndex, xEventFrozen;

void vAddEvent( char cFunction, Msgt *pxMsg, BaseTypet xResult ) { BaseType_t xIndex = xEventIndex;

/* Do not touch the event list while
it is frozen for inspection. */
if( xEventFrozen != pdFALSE )
{
    Event_t *pxEvent = &xEvents[ xIndex ];
    if( ++xIndex == EVENT_COUNT )
    {
        xIndex = 0;
    }
    xEventIndex = xIndex;
    pxEvent->cFunction = cFunction;
    vExtractMsg( pxMsg, pxEvent->pcMsg, sizeof( pxEvent->pcMsg ) );
    pxEvent->xResult = xResult;
    /* Get a time-stamp with uS precision. */
    pxEvent->ulTime = ulGetPrecisionTime();
}

}

~~~~~

At some point, when the error occurs, you can inspect the data produced in the circular buffer.

Regards.


Queue data order change?

Posted by gigglergigger on October 26, 2015

Hein Tibosch,

Thanks for your reply. I'm not sure why I cannot breakpoint the queue or read data without loosing it but I've confirmed it's getting the data in the correct order.

It's my CAN bus driver - the output FIFO's are submitting frames to the bus in a strange order.

Regards,

dc


[ 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