STM32F4 FreeRTOS thread awareness pain in TrueStudio

[andrew239955_stm1_stmicro_com]

I have been working with the STM32F427 using CubeMX and TrueStudio for a couple of years now, and getting freertos thread awareness into the debugger has been a constant challenge. Sometimes it works, sometimes it doesn't ...

My current situation, using a J-Link and the latest DLL from Segger, is that clicking pause works just fine, but hitting a breakpoint does not. When I click pause, the tasks are laid out nicely and (so far as I can tell) correctly. When I hit a breakpoint, the task information is not read correctly and the task view is garbled (with heaps of read alignment errors visible in the gdb log).

Yesterday, I stumbled across a post that linked this behaviour to configUSE_PORT_OPTIMISED_TASK_SELECTION .. and if I manually disable this (ie: it's enabled in CubeMX and greyed out), everything works correctly. Unfortunately, this means that there's a performance hit to context switches, so it's not ideal.

Apparently FreeRTOS 10.0.0 introduced freertos_tasks_c_additions.h, which helps in dealing with this, but I'm stuck at 9.0.0 unless I unhook from the Cube environment.

I've looked at CubeIDE and it looks like it has the same problems ..

Thoughts/comments?

Edit: apparently FreeRTOS 10 should be supported for my MCU ... I'll have a dig and see if I can work out why I'm still on v9.0.0!

[Pavel A.]

FreeRTOS 10 is included in other Cube packages, for example H7. You can borrow it from there.

-- pa

[andrew239955_stm1_stmicro_com]

yeah .. it looks like I need to update. 10 is supported in later firmware/CubeMX ... unfortunately I have applied a reasonable amount of customisation to my CubeMX generated code:

• modified the USB code to not use malloc/free and also give me unique IDs
• modifed SPI timeouts
• modified UART Rx code to facilitate "rx forever"

amongst other stuff. Moving forward means I need to go over these mods again and either reinstate them or discard them (eg: I see the newer USB code looks like it probably provides unique IDs on its own).

I'm currently trawling through the generated project code .. I need to get to a place where my code will at least start so that I can see whether it's worth the effort :)

eg: it looks like freertos_tasks_c_additions.h is still not generated, so I'm not sure whether the generated code won't just be prone to the same problems.

[andrew239955_stm1_stmicro_com]

nope! CubeMX 5.6.1 with FreeRTOS v10 does exactly the same thing :(

[andrew239955_stm1_stmicro_com]

okay .. success! and not just with migrating to FreeRTOS v10

A file by the name of freertos_tasks_c_additions.h is the key .. as is convincing the linker not to optimise out the FreeRTOSDebugConfig[] constant it creates.

I worked everything out in CubeMX 5.6.1 (with FreeRTOS v10) and then retrofitted to my FreeRTOS v9 project. This ultimately is a "safer" path for me as it means I don't need to regression test a new build (my Software Test Suite takes a couple of days to work through).

FreeRTOS v10 adds an "automatic" way of including a file by the name of freertos_tasks_c_additions.h (which comes from NXP originally I think), but it can be added manually to earlier versions (the file itself hints that v7.5.3 is the earliest).

I downloaded and installed NXP's MCUXpresso to get freertos_tasks_c_additions.h

I then copied it in one of my project include directories. I manually edited tasks.c to include the following at the end:

#if( configINCLUDE_FREERTOS_TASK_C_ADDITIONS_H == 1 )

#include "freertos_tasks_c_additions.h"

#ifdef FREERTOS_TASKS_C_ADDITIONS_INIT

  static void freertos_tasks_c_additions_init( void ) {

   FREERTOS_TASKS_C_ADDITIONS_INIT();

  }

 #endif

#endif

(this is already there for FreeRTOS v10+, so the manual edit isn't necessary)

I then manually edited FreeRTOSConfig.h with this line in the USER CODE BEGIN Defines section:

#define configINCLUDE_FREERTOS_TASK_C_ADDITIONS_H 1

Note that you need to configure FreeRTOS to enable USE_TRACE_FACILITY in the FreeRTOS config parameters.

I then added a reference to FreeRTOSDebugConfig[0] in my code so that the linker didn't optimise the array away.

So far it all looks good. Breakpoints in tasks, inside ISRs etc all give me what looks like the correct task list.

phew =)