Quality RTOS & Embedded Software

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


gcc / gdb related issue

Posted by Nobody/Anonymous on January 9, 2007

Maybe my question is not so FreeRTOS specific but I ran into it while trying out FreeRTOS.

Im using:
yagarto toolchain/eplipse/openocd
target board is based on SAM7A1

The problem is that debugger is not able to show variables correctly. I used the same "naked" attribute as serial port demo for FreeRTOS:

void vUART_ISR( void ) __attribute__ ((naked));

void vUART_ISR( void )

portBASE_TYPE xStatus;
portBASE_TYPE a;
portBASE_TYPE xST, xMask, xDummy;
portBASE_TYPE xTaskWokenByTx = pdFALSE, xTaskWokenByRx = pdFALSE;

xST= USART1->SR; <---------------I inserted brakepoint here
xMask= USART1->IMR;
xStatus= xST & xMask;

I checked the assembly output of the compiler. Variables are inserted below the sp as C compiler is used to do (as I understood it so far) and interrupt mask registers and everything seems reasonable. But eclipse debugger (as well as insight) shows totally different values and does not change the value as program reads status/mask registers. Same thing for xTaskWokenBy..., despite assembly output initialises these values and inserts below the sp, debugger has different opinion about the values... This is rather annoying while debugging and I guess everything that does not work correctly can cause a lot of trouble...

My C and linker flags are the following:
DEBUG=-ggdb (also tried -g)

-I. \
-I../FreeRTOS/Source/include \
-I../FreeRTOS/Demo/Common/include \
$(DEBUG) -mcpu=arm7tdmi \
-T../script/SAM7A1-ram.ld \
-Wcast-align $(OPTIM) -fomit-frame-pointer

LINKER_FLAGS=-Xlinker -ortosdemo.elf -Xlinker -M -Xlinker -Map=rtosdemo.map -Wl,--cref,-L../lib,-lSAM7A1

Thank you in advance!

RE: gcc / gdb related issue

Posted by Jeff Smith on January 10, 2007
One case where I don't see the right variables is if I compile with '-fomit-frame-pointer' but the debugger doesn't support it. Of course the solution would be a debugger that supports it There's good reason why __attribute__((naked)) is required by FreeRTOS, otherwise removing it would probably make the debugger work.

The bottom line is that FreeRTOS is by design, dificult to debug all the way through. I use other methods of debugging those parts (i.e. add code to output trace information).

[ 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.

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.


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


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