Bigger binary/ with CMake

[Andrej Pi�ek]

Hello,

We considered using the STM32 VScode extension for our next project but encountered a strange issue.

In cubeMX, I created an empty project for STM32U5G9J-DK2, with FreeRtos, NeoChrome and everything related.
When I built this project with CMake, flash usage exceeded 2MBs even when built with the "MinSizeRel" flag.

I found it a bit odd, so I tried other compilers.
CubeIDE managed to build it with ~250kB.
IAR with ~220kB

I thought the problem lies in NeoChrome libraries, but CMake and CubeIDE use the same.

No settings were changed during the tests, only project generation in CubeMX.
What could be causing this excess in consumption, which is almost 2MB?

I would much appreciate any advice.

Here are some additional details...
Changing optimisation levels didn't make more than 50kB of difference for any compiler.

IAR with no optimisation:

CubeIDE for Debug:

 CMake optimised for size:

Regards,
Andrej

[Nawres GHARBI]

Hi @Andrej Pi�ek 

could you share your project please we are interested to test the build in our env

[mattias norlander]

@Andrej Pi�ek , did you figure it out?

Can you compare the map-files of the project built with CubeIDE vs the one built with CMake.
In CMake context you can have a look at the compile_commands.json to see how the compiler is invoked for each C-file. Compare that with the invocation to the same file from the compilation output in the build console of CubeIDE. Flags should be the same --> Result should be the same...

...Just two pointers to help you on the way.

[Rob.Riggs]

I ran into the same problem recently. In my case, the problem was two-fold.

First, it took me a while to figure out that some of the compiler and linker options I had specified manually in STM32CubeIDE were not reflected in the CMake build, and it took me some time to figure out the proper way to add these same options to the CMake build.

Second, some of my error handling macros included __FILE__ in the output (even for release builds). This embeds the path of the file as seen by the compiler. This is much longer with CMake than Eclipse due to the way CMake builds are done. For a relatively small build (~200kB), this added 3kB of just additional text for path names. The work-around I used which saves space in both Eclipse and CMake builds is to use the __FILE_NAME__ macro instead.