# Debugging is not wroking from Eclipse after migrating with v10.0.0 **URL:** \ **Category:** Kernel\ **Created:** [February 6, 2018, 5:36am UTC](https://forums.freertos.org/t/debugging-is-not-wroking-from-eclipse-after-migrating-with-v10-0-0/6994 "2018-02-06T05:36:59Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [February 6, 2018, 5:36am UTC](https://forums.freertos.org/t/debugging-is-not-wroking-from-eclipse-after-migrating-with-v10-0-0/6994/1 "2018-02-06T05:36:59Z")
**[poulamee](https://sourceforge.net/u/poulamee/)** wrote on [Tuesday, February 06, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/932eba9c/#da0c): 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, ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [February 6, 2018, 5:46am UTC](https://forums.freertos.org/t/debugging-is-not-wroking-from-eclipse-after-migrating-with-v10-0-0/6994/2 "2018-02-06T05:46:23Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Tuesday, February 06, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/932eba9c/#da0c/bcad): 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. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [February 7, 2018, 4:41am UTC](https://forums.freertos.org/t/debugging-is-not-wroking-from-eclipse-after-migrating-with-v10-0-0/6994/3 "2018-02-07T04:41:21Z")
**[poulamee](https://sourceforge.net/u/poulamee/)** wrote on [Wednesday, February 07, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/932eba9c/#22bd): 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 ? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [February 7, 2018, 7:54am UTC](https://forums.freertos.org/t/debugging-is-not-wroking-from-eclipse-after-migrating-with-v10-0-0/6994/4 "2018-02-07T07:54:33Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, February 07, 2018](https://sourceforge.net/p/freertos/discussion/382005/thread/932eba9c/#22bd/f762): 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.