cmsis_armclang.h not included when using STARM_NEWLIB

[wallwhit]

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:

• Toolchain / IDE: CMake
• Default Compiler/Linker: Starm-Clang. I keep wanting to pick Sturm und Drang but sadly that's not an option. ;)

And I modified two of the code-generation settings. From the .txt report:

• STM32Cube MCU packages and embedded software packs : Copy only the necessary library files
• Generate peripheral initialization as a pair of '.c/.h' files per peripheral : Yes

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?

[Ghofrane GSOURI]

Hello @wallwhit 

I'm currently checking this .I will get back to you asap.

THX

Ghofrane

[Ghofrane GSOURI · Accepted solution]

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

[wallwhit]

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.

[ThomasBzt]

Hello @wallwhit 

May I offer some details:

• Arm Compiler 5 is a toolchain made of proprietary tools and libraries, no Clang in there;
• Arm Compiler 6 has a Clang compiler, armclang (with modifications compared to an upstream Clang); but still has a proprietary linker and libraries, and that has some implications on cmsis_armclang.h;
• ST Arm Clang is based on Arm Toolchain for Embedded (Arm Compiler 6's successor, LLVM-based, open source): it is exclusively made of GCC-compatible Clang/LLVM tools: compiler, linker, binary utilities. Although some tools were modified for better optimization, they are still GCC-compatible. This post presents the ST Arm Clang toolchain. You can also take a look at the README.md distributed alongside the toolchain by CubeCLT.

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

[wallwhit]

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

[ThomasBzt]

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

[wallwhit]

Great. Thank you.

Wallace