2025-10-07 9:46 AM
I'm a new user of the STM32 and its tools, and I'm confused about their behavior when using ST's Arm Clang toolchain (not the hybrid Clang-GNU but the full Clang/LLVM). The ST-provided `cmsis_armclang.h` isn't being included in my build of a simple CubeMX-generated project. Instead, `cmsis_gcc.h` is included.
Using the current version of STM32CubeMX (6.15.0), I created a project for the NUCLEO-U545RE-Q board (attached). I used the default settings except that I went with ST's contemporary approach for VS Code with ST's extension pack:
And I modified two of the code-generation settings. From the .txt report:
The generated code's `starm-clang.cmake` defaulted to the hybrid toolchain by using `set(STARM_TOOLCHAIN_CONFIG "STARM_HYBRID")`. I replaced that with `set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")`.
The project builds and runs in debugger mode fine, but I had expected `cmsis_armclang.h` to be included. I confirmed that it is not by renaming that file with no effect on the build. On the other hand, renaming `cmsis_gcc.h` did cause fatal errors.
I see in `cmsis_compiler.h` where this selection of a compiler-centric header file is made, according to macros that I think the toolchain sets. Evidently the toolchain is not defining `__ARMCC_VERSION` as Arm Clang tools normally would (see Arm docs), but it is defining `__GNUC__`, which naturally triggers the inclusion of the GCC header file.
As a test, I modified `cmsis_compiler.h` to bypass its conditional checks of the active compiler and to simply `#include "cmsis_armclang.h"`. The project still built and ran fine.
Should I keep doing that to force the use of what seems like the right header file for my project, or is it somehow correct to use a GCC-oriented header with a full-Clang/LLVM toolchain?
Solved! Go to Solution.
2025-10-10 1:29 AM
Hello @wallwhit
I am sharing our expert feedback with you.
"The concern of the user is understandable due to the naming of these files; however, the default behavior of including cmsis_gcc.h for ST Arm Clang (regardless of the mode) is correct:
The reason is that the U5 firmware package is based on CMSIS version 5, and this version does not provide native support for "vanilla" Clang toolchains such as ST Arm Clang. However, CMSIS 5 provides cmsis_gcc.h which is the appropriate header for GCC-compatible Clang-based toolchains in this version.
While the user observed that cmsis_armclang.h also worked, it is important to note that this header is intented exclusively for Arm ® Compiler 6 toolchains (which include the armclang compiler). There are subtle differences between Arm Compiler 6 and ST Arm Clang, so using cmsis_armclang.h with ST Arm Clang is not supported.
Therefore, we recommend maintaining the default logic of including cmsis_gcc.h when using ST Arm Clang in Cube projects based on CMSIS 5."
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-10-09 5:56 AM
Hello @wallwhit
I'm currently checking this .I will get back to you asap.
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-10-10 1:29 AM
Hello @wallwhit
I am sharing our expert feedback with you.
"The concern of the user is understandable due to the naming of these files; however, the default behavior of including cmsis_gcc.h for ST Arm Clang (regardless of the mode) is correct:
The reason is that the U5 firmware package is based on CMSIS version 5, and this version does not provide native support for "vanilla" Clang toolchains such as ST Arm Clang. However, CMSIS 5 provides cmsis_gcc.h which is the appropriate header for GCC-compatible Clang-based toolchains in this version.
While the user observed that cmsis_armclang.h also worked, it is important to note that this header is intented exclusively for Arm ® Compiler 6 toolchains (which include the armclang compiler). There are subtle differences between Arm Compiler 6 and ST Arm Clang, so using cmsis_armclang.h with ST Arm Clang is not supported.
Therefore, we recommend maintaining the default logic of including cmsis_gcc.h when using ST Arm Clang in Cube projects based on CMSIS 5."
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-10-10 8:08 AM
Thank you, Ghofrane. I will heed that advice.
One needs discerning taste buds to keep track of the various subtypes of vanilla involved here: vanilla Clang, vanilla Arm 6 tools, vanilla Arm 5 with ST sprinkled on top... :)
Is there a section of ST's documentation that I should read to better understand aspects like this?
Thanks again.
2025-10-13 9:40 AM
Hello @wallwhit
May I offer some details:
So ST Arm Clang toolchain is closer to an upstream ("vanilla") Clang/LLVM toolchain, which is GCC-compatible, than to an Arm ® Compiler 6 toolchain.
That's why cmsis_gcc.h is more appropriate than cmsis_armclang.h (even if that sounds counterintuitive!).
Sorry for the confusion introduced with the term "vanilla".
-Thomas
2025-10-13 10:30 AM
Thank you, @ThomasBzt. It I had read the post you linked but had not understood this aspect. Now I do.
Where would I find that particular README.md? I haven't installed CubeCLT, since I'm using the recent STM32 VS Code extension pack that doesn't need it. I looked through the STM32 extensions in `~/.vscode/extensions/` but didn't find a README about this.
Thanks again,
Wallace
2025-10-13 12:37 PM
From VS Code, the content of this README is available in HTML form through:
STM32Cube extension panel on the left-side bar in VS Code -> User guide -> Toolchains -> "Learn more about Arm Clang Toolchain for STM32"
Best regards
-Thomas
2025-10-13 12:58 PM
Great. Thank you.
Wallace