I am testing FreeRTOS on an LPCXpresso board:
I have followed the prompts for "MCUXpresso IDE FreeRTOS Debug Guide "(Rev. 11.2.0 - 7 October, 2020) from NXP:
However, the FreeRTOS TAD task list appears empty and only the current task is displayed in the debug view.
I have been able to fix the task list thanks to https://mcuoneclipse.com/2017/03/18/better-freertos-debugging-in-eclipse/ By disabling the legacy API names in FreeRTOSConfig.h (#define configENABLE_BACKWARD_COMPATIBILITY 0) the task list fills up as if by magic. (I don't know if it is a very specific case, but it would be nice if it was indicated in the FreeRTOS Debug Guide; It would have saved me many hours of frustration).
But despite the fact that the project compiles, runs and works fine, despite the fact that the three tasks (plus the idle) that compose it are displayed in the FreeRTOS TAD task list (with their execution times), in the debug view only shows the current task, the one that was running when stopped.
I copy below the content of the debugging console, because I think the key may be there:
MCUXpresso IDE RedlinkMulti Driver v11.2 (Sep 22 2020 13:23:35 - crt_emu_cm_redlink build 19)
Found part description in XML file nxp_lpc17xx.xme
Reconnected to existing LinkServer process.
Probe Firmware: LPC-Link Probe v1.3 (NXP - LPC-Link)
Serial Number: WIN64HS12
VID: PID: 1FC9: 0009
USB Path:
Using memory from core 0 after searching for a good core
debug interface type = Cortex-M3 / 4 (DAP DP ID 2BA01477) over SWD TAP 0
processor type = Cortex-M3 (CPU ID 00000C23) on DAP AP 0
number of h / w breakpoints = 6
number of flash patches = 2
number of h / w watchpoints = 4
Probe (0): Connected & Reset. DpID: 2BA01477. CpuID: 00000C23. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Disabled.
Content of CoreSight Debug ROM (s):
RBASE E00FF000: CID B105100D PID 0000000000 ROM (type 0x1)
ROM 1 E000E000: CID B105E00D PID 04002BB000 Gen SCS (type 0x0)
ROM 1 E0001000: CID B105E00D PID 04002BB002 Gen DWT (type 0x0)
ROM 1 E0002000: CID B105E00D PID 04002BB003 Gen FPB (type 0x0)
ROM 1 E0000000: CID B105E00D PID 04002BB001 Gen ITM (type 0x0)
ROM 1 E0040000: CID B105900D PID 04002BB923 CSt TPIU-Lite type 0x11 Trace Sink - TPIU
ROM 1 E0041000: CID B105900D PID 04002BB924 CSt ETM-M3 type 0x13 Trace Source - Core
NXP: LPC1769
DAP stride is 4096 bytes (1024 words)
Inspected v.2 On-chip Flash Memory LPC175x_6x_512.cfx
Image 'LPC175x_6x (512K) Sep 25 2020 10:47:33'
Connected: was_reset = true. was_stopped = false
Awaiting telnet connection to port 3336 ...
GDB nonstop mode disabled (using allstop mode)
Opening flash driver LPC175x_6x_512.cfx
Sending VECTRESET to run flash driver
Flash device supported (512KB = 16 * 4K 14 * 32K at 0x0)
Writing 7340 bytes to address 0x00000000 in Flash
Sectors written: 0, unchanged: 2, total: 2
Erased / Wrote sector 0-1 with 7340 bytes in 38msec
Closing flash driver LPC175x_6x_512.cfx
Flash Write Done
Flash Program Summary: 7340 bytes in 0.04 seconds (188.63 KB / sec)
Starting execution using core reset and halt target
Stopped (Was Reset) [Reset from Unknown]
Stopped: Breakpoint # 1
Stopped: Halt
As you can see I am debugging in All-Stop mode. However, I don't get the message "FreeRTOS stack backtrace is enabled". Following the instructions of the FreeRTOS Debug Guide I have added a folder called "linkscripts" to the root directory of the project and I have created a file "user.ldt" with the content:
<#assign force_freertos = true>
It seems that something has improved, as it now mentions FreeRTOS, but it is not the expected result:
GDB nonstop mode disabled (using allstop mode)
FreeRTOS stack backtrace is disabled
Why? Can somebody help me? I insist that the project compiles, runs and works correctly. Tasks are displayed in FreeRTOS TAD task list, execution times are consistent. I can successfully debug the project ... The only problem is that the debug view only shows the current task.
Thanks a lot.
Solved! Go to Solution.
Solved! I have found what the problem was. I apologize for the inconvenience, but don't think I sent the question the first time. I've been working on it for weeks and days thinking about submitting the question.
Hi Erich, nice to meet you. In the last weeks I have used your blog a lot and I have learned a lot. In fact, that's where the solution came from. In https://mcuoneclipse.com/2017/07/27/troubleshooting-tips-for-freertos-thread-aware-debugging-in-ecli... you mention setting INCLUDE_vTaskDelete to 1, and the solution was not far off.
I already had, just in case, INCLUDE_vTaskDelete at 1, configUSE_PORT_OPTIMISED_TASK_SELECTION at 0, ... But as you recommend on the blog, raising the debugging level to 4 I get:
FreeRTOS symbol(s) found:
- "pxReadyTasksLists" 0x10004C18
- "xPendingReadyList" 0x10004C70
- "xDelayedTaskList1" 0x10004C40
- "xDelayedTaskList2" 0x10004C54
- "pxDelayedTaskList" 0x10004C68
- "pxOverflowDelayedTaskList" 0x10004C6C
- "xTasksWaitingTermination" 0x10004C84
- "xSchedulerRunning" 0x10004CA8
- "uxCurrentNumberOfTasks" 0x10004C9C
- "pxCurrentTCB" 0x10004C14
- "FreeRTOSDebugConfig" 0x00001F9C
- "portArch_Name" 0x00001F98
FreeRTOS symbols(s) not found:
- "xSuspendedTaskList" required
FreeRTOS stack backtrace is disabled
I see that FreeRTOSDebugConfig is present, that is not the problem. But it doesn't find xSuspendedTaskList, which is required.
Investigating what is xSuspendedTaskList I find this (lines 3645--3655 of tasks.c)
#if ( INCLUDE_vTaskDelete == 1 )
{
vListInitialise( &xTasksWaitingTermination );
}
#endif /* INCLUDE_vTaskDelete */
#if ( INCLUDE_vTaskSuspend == 1 )
{
vListInitialise( &xSuspendedTaskList );
}
#endif /* INCLUDE_vTaskSuspend */
Where the xTasksWaitingTermination () and INCLUDE_vTaskDelete that you mention in the blog are also displayed. So I set INCLUDE_vTaskSuspend to 1 in FreeRTOSConfig.h and:
GDB nonstop mode disabled (using allstop mode)
FreeRTOS stack backtrace is enabled
Finally! I've been dreaming of that phrase for weeks. In fact, doesn't it appear to be written in gold letters?
I have tried setting INCLUDE_vTaskSuspend to 1 and INCLUDE_vTaskDelete to 0, and it works. I suppose the difference between the program that you were using on the blog and the one that I am using is that yours deleted tasks and mine did not. I dont know. The best thing is to leave both of them to 1 (in fact, I am about to put all INCLUDEs in 1, just in case). My program does not suspend any tasks, so I assume INCLUDE_vTaskSuspend will be used internally. It won't be a bug, but it could give a warning, right?
Thank you very much for your help.
Hello Asiertapiazulai,
It could be that the IDE Debug Mode is not set to All-Stop, which allows a thread aware debug view. Please make sure that you select the All-Stop IDE Debug mode when connecting to the target.
The Non-Stop mode shows the debug information only for the current thread, which I think it’s what’s happening from the screenshot shared.
I hope that this helps!
Regards,
Gustavo
Hello @gusarambula. It seems that you have not read the entire message:
As you can see I am debugging in All-Stop mode. However, I don't get the message "FreeRTOS stack backtrace is enabled". Following the instructions of the FreeRTOS Debug Guide I have added a folder called "linkscripts" to the root directory of the project and I have created a file "user.ldt" with the content:
<#assign force_freertos = true>
It seems that something has improved, as it now mentions FreeRTOS, but it is not the expected result:
GDB nonstop mode disabled (using allstop mode)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FreeRTOS stack backtrace is disabled
Thanks.
Hi @asiertapiazulai ,
I do have occasional problems with LinkServer too. This is how it *should* look like (example LPC845-BRK) with LinkServer:
MCUXpresso IDE RedlinkMulti Driver v11.2 (Sep 22 2020 13:23:35 - crt_emu_cm_redlink build 19)
Found part description in XML file LPC845_internal.xml
Reconnected to existing LinkServer process.
Probe Firmware: LPC11U3x CMSIS-DAP v1.0.7 (NXP Semiconductors)
Serial Number: 11022028
VID:PID: 1FC9:0132
USB Path: \\?\hid#vid_1fc9&pid_0132&mi_00#7&a49518b&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Using memory from core 0 after searching for a good core
On debug connection - reset using system reset
debug interface type = Cortex-M0+ (DAP DP ID 0BC11477) over SWD TAP 0
processor type = Cortex-M0+ (CPU ID 00000C60) on DAP AP 0
number of h/w breakpoints = 4
number of flash patches = 0
number of h/w watchpoints = 2
Probe(0): Connected&Reset. DpID: 0BC11477. CpuID: 00000C60. Info: <None>
Debug protocol: SWD. RTCK: Disabled. Vector catch: Enabled.
Content of CoreSight Debug ROM(s):
RBASE F0000000: CID B105100D PID 0500081000 ROM (type 0x1)
ROM 1 E00FF000: CID B105100D PID 04000BB4C0 ROM (type 0x1)
ROM 3 E000E000: CID B105E00D PID 04000BB008 Gen SCS (type 0x0)
ROM 3 E0001000: CID B105E00D PID 04000BB00A Gen DWT (type 0x0)
ROM 3 E0002000: CID B105E00D PID 04000BB00B Gen FPB (type 0x0)
NXP: LPC845
DAP stride is 1024 bytes (256 words)
Inspected v.2 On-chip Flash Memory LPC84x_64.cfx
Image 'LPC84x (64K) Sep 25 2020 10:46:59'
Connected: was_reset=false. was_stopped=true
Awaiting telnet connection to port 3334 ...
GDB nonstop mode disabled (using allstop mode)
FreeRTOS stack backtrace is enabled
Opening flash driver LPC84x_64.cfx
Sending SYSRESETREQ to run flash driver
Flash device supported (64KB = 64*1K at 0x0)
Writing 30784 bytes to address 0x00000000 in Flash
Sectors written: 0, unchanged: 31, total: 31
Erased/Wrote sector 0-30 with 30784 bytes in 49msec
Closing flash driver LPC84x_64.cfx
Flash Write Done
Flash Program Summary: 30784 bytes in 0.05 seconds (613.52 KB/sec)
Starting execution using system reset and halt target
Stopped (Was Reset) [Reset from Unknown]
Stopped: Breakpoint #1
Stopped: Step
Stopped: Breakpoint #1
Stopped: Step
Stopped: Breakpoint #1
Stopped: Halt
nonstop - GDB killing (vKill) non-existent PID 0xA410 (killing anyway)
GDB stub (crt_emu_cm_redlink) terminating - GDB protocol problem: Pipe has been closed by GDB.
If it does not work the way I expect it: what usually helps is deleting the .launch and let the IDE create a new one.
I hope this helps,
Erich
Solved! I have found what the problem was. I apologize for the inconvenience, but don't think I sent the question the first time. I've been working on it for weeks and days thinking about submitting the question.
Hi Erich, nice to meet you. In the last weeks I have used your blog a lot and I have learned a lot. In fact, that's where the solution came from. In https://mcuoneclipse.com/2017/07/27/troubleshooting-tips-for-freertos-thread-aware-debugging-in-ecli... you mention setting INCLUDE_vTaskDelete to 1, and the solution was not far off.
I already had, just in case, INCLUDE_vTaskDelete at 1, configUSE_PORT_OPTIMISED_TASK_SELECTION at 0, ... But as you recommend on the blog, raising the debugging level to 4 I get:
FreeRTOS symbol(s) found:
- "pxReadyTasksLists" 0x10004C18
- "xPendingReadyList" 0x10004C70
- "xDelayedTaskList1" 0x10004C40
- "xDelayedTaskList2" 0x10004C54
- "pxDelayedTaskList" 0x10004C68
- "pxOverflowDelayedTaskList" 0x10004C6C
- "xTasksWaitingTermination" 0x10004C84
- "xSchedulerRunning" 0x10004CA8
- "uxCurrentNumberOfTasks" 0x10004C9C
- "pxCurrentTCB" 0x10004C14
- "FreeRTOSDebugConfig" 0x00001F9C
- "portArch_Name" 0x00001F98
FreeRTOS symbols(s) not found:
- "xSuspendedTaskList" required
FreeRTOS stack backtrace is disabled
I see that FreeRTOSDebugConfig is present, that is not the problem. But it doesn't find xSuspendedTaskList, which is required.
Investigating what is xSuspendedTaskList I find this (lines 3645--3655 of tasks.c)
#if ( INCLUDE_vTaskDelete == 1 )
{
vListInitialise( &xTasksWaitingTermination );
}
#endif /* INCLUDE_vTaskDelete */
#if ( INCLUDE_vTaskSuspend == 1 )
{
vListInitialise( &xSuspendedTaskList );
}
#endif /* INCLUDE_vTaskSuspend */
Where the xTasksWaitingTermination () and INCLUDE_vTaskDelete that you mention in the blog are also displayed. So I set INCLUDE_vTaskSuspend to 1 in FreeRTOSConfig.h and:
GDB nonstop mode disabled (using allstop mode)
FreeRTOS stack backtrace is enabled
Finally! I've been dreaming of that phrase for weeks. In fact, doesn't it appear to be written in gold letters?
I have tried setting INCLUDE_vTaskSuspend to 1 and INCLUDE_vTaskDelete to 0, and it works. I suppose the difference between the program that you were using on the blog and the one that I am using is that yours deleted tasks and mine did not. I dont know. The best thing is to leave both of them to 1 (in fact, I am about to put all INCLUDEs in 1, just in case). My program does not suspend any tasks, so I assume INCLUDE_vTaskSuspend will be used internally. It won't be a bug, but it could give a warning, right?
Thank you very much for your help.
Hi @asiertapiazulai ,
nice to meet you too :-). And thanks for putting up such a detailed solution, I think everyone else here will appreciate that.
Interesting finding about disabling the task suspension (I think never disabled it, simply because it seems to save only a few code bytes (around 80 I just checked) and I usually do use task suspending anyway.
The need for the debugger to find the right symbols can be tricky as you have found out and as well found in my article(s): FreeRTOS (and other RTOS) tend to forget the need to debug it and provide proper support for it (for example many recent FreeRTOS releases broke the debug support with changing symbols/etc). I have fixed many things in FreeRTOS especially dealing with high code optimizations or with LTO (Link Time Optimizations). Luckly most of my changes are now in the most recent FreeRTOS port, but I still carry on a few more with the port on ErichStyger/McuOnEclipseLibrary: Library of McuOnEclipse components (github.com)
Bottom line: great that you have found it, and I learned something new too :-).
thanks again,
Erich
Thanks to you, Erich.
Asier.
Hi @xohap38721 ,
I'm sorry, but I don't get it? Coming from Google translate maybe?