Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Warnings in tasks.c 5.4.1 IAR

Posted by Geoff Kruse on July 28, 2009
I receive the following warnings in tasks.c in freertos 5.4.1 in IAR arm 5.20 for cortex-m3:

Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 611
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 617
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 672
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 678
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 1551
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 1593
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 1598
Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement freeRTOS\tasks.c 1970

While these warnings seem to have no ill effects, our internal coding standard prohibits having any warnings in our code. Any thoughts on the proper way to resolve these warnings?

RE: Warnings in tasks.c 5.4.1 IAR

Posted by Richard on July 29, 2009
The warning is quite correct, but as far as I recall from inspection, also quite benign. It comes from trying to support lots of different compilers, all of which generate warnings in different and sometimes contradictory ways.

You could try casting away the volatile from one or other side of the statement.

I will take a look at the code lines again to see what can be done. In the provided demos I think you will find the warning is just switched off.

Regards.

RE: Warnings in tasks.c 5.4.1 IAR

Posted by RachelAdamec on February 2, 2011
I ended up satisfying this warning by forcing the order in which these variables were accessed:

xList xlXList;
xListItem xliXListItem;
...
if( xTimeToWake < xTickCount )
{
/* Wake time has overflowed. Place this item in the
overflow list. */
xlXList = *((xList *) pxOverflowDelayedTaskList);
xliXListItem = *((xListItem *) &( pxCurrentTCB->xGenericListItem ));
vListInsert( &xlXList, &xliXListItem);
}
else
{
/* The wake time has not overflowed, so we can use the
current block list. */
xlXList = *((xList *) pxDelayedTaskList);
xliXListItem = *((xListItem *) &( pxCurrentTCB->xGenericListItem ));
vListInsert( &xlXList, &xliXListItem);
}

wouldn't this be 'better' than just turning off the warning?


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


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

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

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner