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

debugging FreeRTOS v8.0.0, Cortex M3, gcc

Posted by wella on April 27, 2014

Hello,

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

Regards.


[ 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