Monday, December 11th 2017, 4:46am UTC+1

You are not logged in.

  • Login
  • Register

Date of registration: Nov 27th 2017

Posts: 5

1

Monday, November 27th 2017, 4:21pm

[SOLVED] Mis-aligned FreeRTOS control block

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.
bermondseyelectronic has attached the following file:
  • j-link.txt (290.03 kB - 14 times downloaded - Last download: Dec 8th 2017, 2:59am)

Date of registration: Nov 27th 2017

Posts: 5

2

Tuesday, November 28th 2017, 8:27am

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.

SEGGER - Arne

Super Moderator

Date of registration: Oct 16th 2015

Posts: 83

3

Tuesday, November 28th 2017, 9:15am

Hi,

you wrote, you have 10% success rate. Is this related to exactly the same binary or to 10% of the builds?

Best regards
Arne

Date of registration: Nov 27th 2017

Posts: 5

4

Tuesday, November 28th 2017, 10:11am

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.

SEGGER - Arne

Super Moderator

Date of registration: Oct 16th 2015

Posts: 83

5

Tuesday, November 28th 2017, 10:31am

If stack size is a problem, maybe some of the FreeRTOS control structures are already damaged.
This will lead to the effect you are experiencing, because the plugin reads pointers and then tries to read memory from this location.

Of course the plugin has no chance to display any reasonable results if any of the control structures are damaged.

But I can only guess here...

Date of registration: Nov 27th 2017

Posts: 5

6

Tuesday, November 28th 2017, 11:15am

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.

Date of registration: Nov 27th 2017

Posts: 5

7

Wednesday, November 29th 2017, 4:33pm

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:

C/C++ Source code

1
#define configTASK_RETURN_ADDRESS   			 0#define configUSE_TRACE_FACILITY 				 1


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.

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 430

8

Wednesday, November 29th 2017, 4:39pm

Hi,

Great to hear that you are up and running again.
We will consider this case as solved now.

Best regards,
Nino