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?