Skip to main content
Associate II
June 10, 2026
Question

Differences between code generated for STM32CubeIDE and CMake

  • June 10, 2026
  • 1 reply
  • 62 views

I’m in the process of moving a project from Standalone STM32CubeIDE to the STM32Cude for VSCode extension.  I fully expected project and configuration changes, but not changes to the source code.

However, if I just change the Toolchain / IDE setting from STMCubeIDE to CMake and regenerate the code I see changes to the Core/Src/syscalls.c and Core/Src/sysmem.c.  files.

For example, the CMake versions of syscall.c and symem.c seems to be an older version based on Copyright being 2025, while STM32CubeIDE version is 2026 (see below).

I also notice I get a very different linker files; different names and content (and again the CMake Copyright date is older).

Why is this?  Is this a bug, or an indication that the two generators have diverged and the Cmake version is not being kept up-to-date?

This potentially negates some of my testing, as it goes against my assumption that moving to VSCode will not change the build ‘because it uses the same code and same toolchain’.  

This is the diff for syscall.c (red is STM32CubeIDE and green is CMake).

 

1 reply

Pavel A.
June 11, 2026

Congratulations, you have sharp eyes!

Indeed, code generation for Cmake has some differences. The most dramatic IMHO is move from gcc with newlib/nano to clang and picolibc.

CTapp.1
Senior III
June 12, 2026

Which also means there will be differences in the generated binary due to compiler code generation and optimization differences - which may expose any previously undiagnosed instances of undefined behaviour or assumptions related to implementation defined behaviour. However, any negative changes should be highlighted when the code is run through testing.

All posts are made in a personal capacity. MISRA C++ Chair, MISRA C WG Member, Director The MISRA Consortium Limited (TMCL)
SJBAuthor
Associate II
June 12, 2026

Will the CMake generated project use a different compiler?  If not then that will reduce differences in behaviour.

Thankfully we’re doing this switch early in code development so it’s likely we’ll rerun all the testing anyway. It’s more about managing expectations in the team.  However I have other projects that are more mature and those I might now resist changing.