I am having trouble debugging with the FreeRTOS gdb plugin. The plugin seems to get confused and something in the debug chain crashes. I am using Eclipse Neon.3 and the GNU MCU J-Link Debugging plugin 4.2.1.201711101735, with J-Link 6.20a. Target is STM32F429ZI running FreeRTOS 9.0.0, with heap in CCMRAM. I attach a log file demonstrating the problem (see line 1777). GDB reports "WARNING: Mis-aligned memory read: Address: 0x00000012, NumBytes: 4, Alignment: 4 (Word-aligned) WARNING: Failed to read memory @ address 0xD51D0834 ERROR: Error reading thread name in FreeRTOS task control block." Flash is mapped to address 0 in this application. I believe this MCU is internally capable of unaligned access on DBUS. I am not sure why this address is being accessed, however. It doesn't tie up to any vector address (which should be word-aligned). Unaligned access is set to toolchain default in the settings file. I have tried forcing aligned access and forcing unaligned access, but neither makes any difference.


Confusingly, sometimes when I build and run this it just works, but it's something like 10% of debug sessions, so not very useful.

Any help you can offer would be great.

Preliminary results from last night showed some improvement on 6.22, but this has not been reflected in this morning's testing. Release notes show an issue fixed in 6.12.c, which does not seem related since no tasks have zero length names.

FreeRTOS has been patched with the SystemViewer patch from the 2.52 release, but no connection can be established to the target.

Thanks Arne. Success rate relates to the builds, not the individual binaries produced. Task stack size seems to be part of the problem, although it is quite tricky for me to measure since I have the chan FAT libraries as well as a pre-built EmWin image in the project, and ST's latest SD card driver introduces multitasking support (there's a message queue to pause the task while DMA completes the data transfer to/from the card). It is challenging to debug without stable gdb or SystemView.

Thanks Arne. Now that I am looking for them, I see tasks disappearing while the application is running. gdb no longer crashes, so I must have improved something. GNU MCU Eclipse provides some startup files which differ to the startup routines implemented under ST's Cube configurator. Configuration is now in C and the linker, instead of using a startup assembly file. While I can't see any significant differences, it's possible this could be related to the problem. I will update this thread when I have worked out what has changed, but at least I can get meaningful debug information from the machine now.

Hi Arne, thanks for your help. It turned out to be stack related, just not in the way we were proceeding.

In case anyone else has similar problems, I would occasionally see task stacks relating to the wrong task in the thread view reported by gdb.


I was missing:


These are omitted by v1.16.0 of the STM32F4Cube when it generates FreeRTOSConfig.h. Another symptom of missing the first of these is that the top of stack address in the thread viewer is wrong before the change is made.

I find this plugin very useful when debugging FreeRTOS targets, so thanks for providing it.