Debugging is not wroking from Eclipse after migrating with v10.0.0

poulamee wrote on Tuesday, February 06, 2018:

Hi,

I’m previously using FreeRTOS v7.5.2, I have faced issue after migrating with v10.0.0 in our project . I’m using EFM32GG395F1024 microcontroller with SEGGER J-Link GDB server v5.02.
From Eclipse Luna and Mars both version I’ve tried. Normal build it is working fine . But In Debugging when I’m trying, the GDB server has read the 4 byte address continuously and its showing target request failed (timeout error ).

In FreeRtosConfig.h file I’ve added the macro

####define configENABLE_BACKWARD_COMPATIBILITY 1

and I’ve removed one macro defination

####define configUSE_CO_ROUTINES 1

Is anyone has faced the same type of issue ?
Any help for resolving this issue would be much appreciated!

Thanks in advance,

rtel wrote on Tuesday, February 06, 2018:

There is really nowhere near enough information in your post to know how
to answer. On first read I would say FreeRTOS is just C code so should
not effect whether the debugger is able to read a variable or not.

How far did you get? Where you able to download the program? Were you
able to break at main? Which 4 bytes is the debugger trying to read
when it has a problem? Did any code run at all? Does the program run
if you don’t try debugging?

If unwinding the stack is the cause of the problem then you can try
#defining configTASK_RETURN_ADDRESS to 0 (or NULL) in FreeRTOSConfig.h
so the debugger does not try unwinding past the end of the task’s stack
frame.

poulamee wrote on Wednesday, February 07, 2018:

After using the configTASK_RETURN_ADDRESS to 0 in FreeRTOSConfig.h , it is wroking .
Thank you very much for this solution .
Now debugging is running as expected.
But can you give me more information about this macro(configTASK_RETURN_ADDRESS )
If I’m making this as 1 what will happen ?

rtel wrote on Wednesday, February 07, 2018:

When a task is created an initial stack frame is created. One of the
positions on the stack holds the function return address - but as
functions that implement tasks have nothing to return to the return
address is set to an error handler. If you incorrectly try to exit a
task by simply returning from the task’s implementing function you end
up in the error handler.

When a debugger tries to unwind a task’s stack it can get confused by
the error handler and, not recognising that as the end of the stack,
attempt to unwind further. The macro you set overrides that behaviour
by replacing the address of the error handler with 0 (NULL), which the
debugger recognises the invalid address and does not attempt to unwind
further.