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