STM32Cube further facilitates code development with Clang/LLVM support

[Maxime_MARCHETTO]

Clang/LLVM toolchain project overview

For over a decade ST has offered GNU tools for STM32 as the free, reference toolchain when developing STM32 applications. It is well supported across the complete STM32Cube ecosystem and will continue to be maintained by ST.

The Clang/LLVM toolchain will over time offer STM32 developers better code density and execution speed. This release is a first step on the journey towards better toolchain performance and increased STM32Cube ecosystem integration. The toolchain will be supported within STM32CubeMX and with STM32Cube for Visual Studio Code.

This release provides a first version of the ST Arm Clang toolchain built on the Arm LLVM source tree. It allows early adopters to try a toolchain with a similar performance compared to today’s GCC. It offers more sanity checkers, more optimized C libraries, while compiler benchmark figures will come later.

Further to this initial release, developers can expect two additional steps:

• Feedback collection  
  Early adopters will be provided the opportunity to share feedback, allowing ST to finetune the toolchain and ensure its level of integration across the STM32Cube ecosystem meets expectations. 

• Toolchain optimization 
  ST will adjust the toolchain with the aim to improve code density and execution speed.

Embracing a step-by-step approach ensures that we set priorities in the development phase, in accordance with developer feedback. The ST Arm Clang flavor will soon provide example projects, and STM32CubeMX and STM32Cube for Visual Studio Code will help STM32 developers get started in the meantime. 

What the ST Arm Clang toolchain offers

ST Arm Clang is a new C/C++ toolchain for STM32 development, which is built on the modern LLVM compiler infrastructure and the Arm Toolchain for Embedded.

This new LLVM-based toolchain provides developers with a more efficient, flexible, and future-proof development environment while maintaining compatibility with existing projects.

ST Arm Clang is designed as a drop-in replacement for the GNU tools for STM32, minimizing disruption for developers transitioning to it. However, several minor incompatibilities or divergent features may exist due to the differences in the underlying infrastructure. To ease this transition, we provide two versions of the toolchain:

• Hybrid toolchain: only the C/C++ LLVM Clang compiler and the integrated assembler are used to compile the code into object files (local applications, HAL, etc.). The final binary is built using the tools and libraries from the existing GNU tools for STM32 (GNU Binutils linker, C/C++ libraries, and runtime). This hybrid version is ideal for developers looking to test or leverage Clang's compilation while retaining the familiar GNU linking and runtime environment. Both toolchains (Clang and GCC) should be installed on your system, and link-time optimization (LTO) is not available in this mode.
• Full LLVM toolchain: this version offers the complete long-term LLVM-based solution (Clang compiler, LLVM linker and runtime) with updated libraries, such as Picolibc or LLVM libc++. It benefits from the combined effort from the LLVM community, as well as Arm and ST research and development teams to reach optimal support, performance, and code-size on STM32 devices. The toolchain offers two distinct C library implementations, allowing developers to choose based on their project priorities or device resources: Newlib for performance and Picolibc for code size.

STM32CubeMX support 

The STM32CubeMX version 6.15 introduces support for ST Arm Clang. More specifically, STM32CubeMX generates projects for the hybrid flavor of the ST Arm Clang toolchain. This will allow STM32 developers to quickly try their existing GCC projects with ST Arm Clang toolchain without having to write a new linker script or consider incompatibilities between Newlib and Picolibc. 

Selecting the combination of CMake and ST Arm Clang will create a project targeting the hybrid toolchain:

If users wish to switch from the hybrid to the full LLVM flavor, they can do so inside STM32Cube for Visual Studio Code , following the explanations below.

STM32Cube for Visual Studio Code

Developers can choose between two options to start a project within the STM32Cube ecosystem.

1. Use STM32CubeMX to generate a configurable project
2. Use STM32Cube for Visual Studio Code to generate an empty project

This tutorial is based on the assumption that a project was created with STM32CubeMX as shown in the previous chapter.

How to import an STM32CubeMX project and initiate the Visual Studio Code environment

 Inside STM32Cube for Visual Studio Code, open the folder containing the project generated with STM32CubeMX.

 

Select the folder where STM32CubeMX generated the project.

Allow STM32Cube for Visual Studio Code to load the STM32 extension. You will be asked to configure the project and an STM32Cube project, and select Yes.

Visual Studio Code will read the project metadata and detect whether the ST Arm Clang toolchain is installed or not.

If this is the first time that a project is created targeting this new toolchain, the environment will automatically download, install, and activate this toolchain for this project. The download size is ~700 Mbytes and the installation footprint is 2.5 Gbytes.

The Visual Studio Code environment is not reconfigured to use ST Arm Clang globally. The toolchain selection and management of environmental paths are managed locally inside Visual Studio Code and can be unique to each project.

Building the project and analyzing the results

When the installation of ST Arm Clang is complete, CMake is invoked to run the configure step on the project.

The new ST Arm Clang toolchain as can be seen in the CMake/Build output channel.

Click the build button to build your project.

 

The result is shown in the output console. A build analyzer is available to give further insights into the build result. Right-click on any map-file and select Open memories analysis.

Understanding the CMake file structure and how to select the toolchain

The CMakePresets.json is using the file starm-clang.cmake as the CMake toolchain file.

 

This line would point to gcc-arm-none-eabi.cmake if STM32CubeMX was generating this file targeting GCC. STM32CubeMX 6.15 and later versions will generate both gcc-arm-none-eabi.cmake and starm-clang.cmake in parallel to allow developers to switch toolchains from inside the IDE. STM32CubeMX will generate these two files only once and never modify them again.

The accompanying starm-clang.cmake will allow developers to select which C library combination to choose.

 

By default, the hybrid  version of the ST Arm Clang toolchains is selected since it has the closest compatibility vs the existing GNU tools for STM32. We recommend developers to try building and testing their code with this toolchain. This transitional step will help them become more familiar with this version before using the full LLVM flavor relying on either Newlib or Picolib by switching the value of the variable STARM_TOOLCHAIN_CONFIG as seen above.

The STM32Cube for Visual Studio Code user guide provides additional documentation on ST Arm Clang and additional resources will be added soon based on feedback.

How to use ST Arm Clang with STM32CubeIDE

For the time being, ST Arm Clang is not integrated in the STM32CubeIDE installation package due to its significant size that could impair user experience. However, it will be supported in STM32CubeCLT from the 1.19.0 version. You can follow the steps below to install and set it up for your next project.

How to install STM32CubeCLT

1. Download STM32CubeCLT from this link:  STM32CubeCLT- STMicroelectronics
   
2. Install the package using this document installation-guide-stmicroelectronics.pdf

How to import an STM32CubeMX project and initiate the Visual Studio Code environment 

In STM32CubeIDE, go to File > New > STM32 CMake Project

Since the project has been generated with STM32CubeMX, select “Project with existing CMake sources”.

Name the project and select the folder containing the project generated with the STM32CubeMX.

The project will be imported into the current workspace.

You can now start building your project. The compiler will be detected automatically.

Additional resources

• Product overview - STM32CubeMX 
• Product overview - STM32Cube for Visual Studio Code
• STM32CubeCLT
• STM32CubeMX
• STM32Cube for Visual Studio Code
• Application note - CMake

First published on Jul 08, 2025

 

[unsigned_char_array]

I can't seem to setup a project.

• windows 11
• vscode Version: 1.104.1
• clang 19.1.5 C:/LLVM-ET-Arm-19.1.5-Windows-x86_64/bin/
• STM32CubeIDE for Visual Studio Code 2.1.1
• STM32CubeMX 1.15.0 (to C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMX_V6.15.0"
• STM32CubeCLT 1.19.0 (to C:\ST\STM32CubeCLT_1.19.0)
• create project in STM32CubeMX for NUCLEO-L476RG (CMake, clang, C/H-files separately, nothing else changed) and generate
• open folder in VS Code
• in STM32 VS CODE EXTENSION: import CMake project
• gives error that CLT is not found, so added the path to it: C:\ST\STM32CubeCLT_1.19
• F1: CMake build

building:

[main] Building folder: C:/source/blinky/build/Debug 
[main] Configuring project: blinky 
[proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=C:/source/blinky/cmake/starm-clang.cmake -S C:/source/blinky -B C:/source/blinky/build/Debug -G Ninja
[cmake] CMake Error: CMake was unable to find a build program corresponding to "Ninja". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
[cmake] -- Configuring incomplete, errors occurred!
[cmake] See also "C:/source/blinky/build/Debug/CMakeFiles/CMakeOutput.log".
[proc] The command: "C:\Program Files\CMake\bin\cmake.EXE" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE=C:/source/blinky/cmake/starm-clang.cmake -S C:/source/blinky -B C:/source/blinky/build/Debug -G Ninja exited with code: 1

Previously I was able to get something to work with my own tool chain: https://community.st.com/t5/stm32cubemx-mcus/sysmem-c-build-error-in-clang/td-p/775105 . I wanted to see if I can get the STM32CubeMX support for Clang working. 

[GCsor]

Hi @unsigned_char_array ,

The default generated CMakePresets.json sets the generator to ninja, but VS Code (as far as I remember) doesn't come with a bundled Ninja anymore. You can download the binary, and set the path inside CMAKE_MAKE_PROGRAM:

 {
 "name": "default",
 "hidden": true,
 "generator": "Ninja",
 "binaryDir": "${sourceDir}/build/${presetName}",
 "toolchainFile": "${sourceDir}/cmake/gcc-arm-none-eabi.cmake",
 "cacheVariables": {
 "CMAKE_MAKE_PROGRAM": "ninja"
 }
 },

For me ninja.exe is in the PATH, so I just wrote ninja, but you can specify the full path too. Also if you want to use clang, then you should change the toolchainFile to the starm-clang.cmake one.

 

[Nawres GHARBI]

Hi @unsigned_char_array 

Thanks for the feedback but you are running an old version, please switch to the latest pre-release 3.6.3

I also invite you to submit any feedback or issue under the STM32CubeIDE for VSCode community 

STM32CubeIDE for Visual Studio Code (MCUs) - STMicroelectronics Community

[unsigned_char_array]

@Nawres GHARBI

Thanks. Building works after updating STM32CubeIDE for Visual Studio Code to pre-release (3.6.3) and restarting VS Code. Didn't need to change anything!
I can flash the elf file with STM32CubeProgrammer right away.
But debugging from VS Code (with I selected STLink GDB Server) failed initially:

[Window Title]
Visual Studio Code
[Content]
bound doStepSettingsValidation Failed: Core not found: run "Setup STM32Cube project(s)" 
command or verify "deviceCore" attribute
[Open 'launch.json'] [Cancel]

After running STM32Cube plugin: Setup STM32Cube project(s) and selecting CLANG and STM32L476RG Nucleo board:

Installing cube bundle: st-arm-clang@19.1.6+st.9

Now RUN AND DEBUG works!

[unsigned_char_array]

The new plugin makes python debugging in vscode crash.
I found someone else with the same issue:
https://community.st.com/t5/stm32cubeide-for-visual-studio/error-while-debugging-other-python-projects/td-p/827224

When will this bug be fixed?

[JNT]

This is huge!  There are definitely some bugs, but it's super exciting to see ST better support LLVM compilers!

[hxyulin]

When using starm-clangd, system headers (like <string.h> and <math.h>) are not recognized, but the code sstill compiles. I believe this is a bug with starm-clangd?

[unsigned_char_array]

@hxyulin what do you mean "not recognized"? Syntax highlighting? Header navigation? That requires setting up VS Code properly so the editor uses the same include path settings as the compiler.

[hxyulin]

@unsigned_char_array 
Sorry for not being clear about this.

I am using generated compile_commands.json from the build (symlinked to the project root), using neovim with the starm-clangd as lsp. All functions work correctly, including recognizing headers for the STM32, but certain system libraries, like <string.h>, <math.h>, are not recognized (lsp reports an error when attempting to include: '1. In included file: 'math.h' file not found [pp_file_not_found]'), and I am not able to navigate to the headers. Furthermore, symbols provided by these headers, such memset, malloc, are also not recognized ('1. Call to undeclared library function 'malloc' with type 'void *(unsigned int)'; ISO C99 and later do not support implicit function declarations (fix available) [-Wimplicit-function-declaration]').

I have attempted to add the --query-driver parameter to clangd, providing both the GNU-tools-for-STM32 and st-arm-clang. I am using STM32CubeCLT version 1.19.0.

[unsigned_char_array]

@hxyulin sounds like your editor doesn't see the sysroots. With me (windows) it's in \AppData\Local\stm32cube\bundles\st-arm-clangd\19.1.2+st.3\lib\clang\19. The bundles folder path is stored in the environment variable env:CUBE_BUNDLE_PATH set by the plugin. If you call starm-clang.exe -print-resource-dir it will return the path of the includes. In my case C:\ST\STM32CubeCLT_1.19.0\st-arm-clang\lib\clang\19. Both these include paths have the same files. I think the one in appdata is a copy from the CLT-installation.

Furthermore in my build folder there is a file: build\Debug\.cmake\api\v1\reply\toolchains-v1-f647a87e511362ab4288.json. Which has a parameter "includeDirectories". So all the information needed for the editor is in the build folder. If you can build you should be able to navigate to includes.
It sounds like you are working on Linux. Just make a new topic if you cannot solve it. You can mention me via @ in that topic and I'll take a look at it.