Quality RTOS & Embedded Software

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


debugging FreeRTOS v8.0.0, Cortex M3, gcc

Posted by wella on April 27, 2014


with the recent version of arm-none-eabi-gcc version 4.8.3 20140228 (release) and FreeRTOS v8.0.0 I am getting stucked during debugging on Cortex - M3 core within Eclipse.

My GDB server (segger) shows me that there is an attempt to read from undefined memory after halting the programm. It is caused by trying to read data from the stack frame (e.g. info stack command). Somewhere in the deep, the stack frame pointer has random value and the gdb generates a read request with a random address.

It is caused by filling the stack with a overflow-check-value and pxPortInitialiseStack function. The frame pointer points to random data. I had to set the LR back to 0 (as v7.5.2). GDB stops here (stack frame ends at 0x00000) but still generates request to read from address 0x0000000.

Does anybody else have this issue? Or am I the only one because I did not find anything on the net about it :).

Best Martin

debugging FreeRTOS v8.0.0, Cortex M3, gcc

Posted by rtel on April 30, 2014

[Sorry it took so long for you post to appear. For some reason it went into the moderation queue - I have no idea why and it took me three days to notice as I didn't get any notification that that had happened]

First question is, is this issue actually preventing you from using the debugger, or is it just an inconvenience? If it is just an inconvenience then I would suggest just ignoring it.

When the debugger stops it attempts to unwind the stack frame so it can show it in the threads window within Eclipse. I'm not entirely sure how it knows when to stop unwinding, but as you found out, setting a return address of 0 at some point at least sets it know it has found something it doesn't think is right and that it shouldn't look any further. The debugger knows nothing about multitasking or tasks, and doesn't know that the task does not necessarily have a return address.

In FreeRTOS you cannot return from a function that implements a task. If you want a task to exit you instead have to call vTaskDelete( NULL ). Recent versions of FreeRTOS trap users attempting to return from a function by setting the task's return address to an error function that contains an assert(). There is no way out of that function, hence the debugger can get confused when it attempts to unwind its stack - and this is no doubt the problem you are experiencing.

Vanilla GCC with GDB appears to be the only combination that complains about this so there is a built in way of attempting to keep it happy. To set the return address to 0, as per previous FreeRTOS versions, just add the following lines to your FreeRTOSConfig.h file:

#define configTASK_RETURN_ADDRESS 0


[ 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