Sizeof() returning different values compiling on with STM32Cube IDE and PlatformIO for FreeRTOS type

Hi All,

I generated some code with STM32Cube IDE and structured it to be compiled with PlatformIO STM32 platform.

I’m also using LwIP and FreeRTOS that were copied from STM32CubeIDE as libraries in PlatformIO.

I’m having some issues because some of threads are not being created when compiling with PlatformIO and I notice that is because the heap gets out of memory (Heap4.c).

I also notice that the function sizeof() returns different values when compiled with STM32Cube IDE and PlatformIO for same datatype. More specifically this code:

sizeof( TCB_t ) # tasks.c file

that returns 180 bytes when running compiled with STM32Cube IDE and 1152 bytes when compiled with PlatformIO.
TCB_t is a data structure from FreeRTOS files, which I’m using the same in STM32CubeIDE and PlatformIO.

This is my configuration:

platform = ststm32
board = genericSTM32F407VET6
framework = stm32cube
board_build.stm32cube.custom_config_header = yes
board_build.stm32cube.custom_system_setup = yes
board_build.stm32cube.startup_file = startup_stm32f407vgtx.s
board_build.ldscript = $PROJECT_DIR/STM32F407VETX_FLASH.ld

platform_packages =
    framework-stm32cubef4 @

upload_protocol = stlink    

build_type = release
build_flags = -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -DHSE_VALUE=16000000L -fstack-usage -O0 -fdata-sections -MMD -MP -g3

build_type = debug
debug_tool = stlink
debug_build_flags = -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -DHSE_VALUE=16000000L -fstack-usage -O0 -fdata-sections -MMD -MP -g3 -Og
debug_init_cmds =
  target extended-remote $DEBUG_PORT
  monitor reset halt
  monitor init
  monitor reset halt

Any idea why this might be happening? Different version off gcc/toolchain used? Some config missing while compiling?

Thanks in advance!

Definitely looks like some configs are off.
If you look at the control block content FreeRTOS-Kernel/tasks.c at aa987a3443b60894bc64714135bca44831406886 · FreeRTOS/FreeRTOS-Kernel · GitHub a lot of it’s data is controlled by if-defs. Maybe you can find the definitions used by STM32Cube by running a verbose build and seeing which of these values are defined.

I’ve tried to check the configuration values and they are all the same :frowning:

Also make sure I’m using same toolchain in both STM32 Cube IDE and Platformio, toolchain-gccarmnoneeabi 10.3.1. and structure my project to be ‘baremetal’ without framework but problem still occurs.

What it could be the function sizeof() return quite different values when built wit STM32CubeIDE and Platformio?

This can happen due to alignment of variables within a struct. Do you need to use the ‘packed’ attribute???
Another alternative is the default size of an ‘int’ variable (although if you are using the same compiler with the same default options then this should not be the case).
Just guessing

The only way to know what’s going on here is if you upload both PlatformIO project and STM32CubeIDE projects in full (e.g. zip file), otherwise it’s just guessing in the dark.

It seems I was able to fix it. I copied the exact same compile and linker flags from STM32Cube IDE to a separate script file, I also added the missing pre: to make sure gets configured before execution.

Note: The flag -fcyclomatic-complexity was not recognized by gcc when compiling with PlatformIO even tough I seem to use the same tool chain. A bit strange.

I end up with following files now seems to work:

platform = ststm32
board = genericSTM32F407VET6
board_build.stm32cube.custom_config_header = yes
board_build.ldscript = $PROJECT_DIR/STM32F407VETX_FLASH.ld

upload_protocol = stlink    

platform_packages =
  toolchain-gccarmnoneeabi @ 1.100301.220327

lib_deps = 

build_flags =

extra_scripts =

lib_archive = no




I’m not exactly sure which flag made the change/fix but now seems working. I also put all config related flags in python file itself, since I don’t exactly know which flags in build_flags property goes where.

Maybe later I will try to understand which flag made the change fix.