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?
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.