Skip to main content
Lead II
November 7, 2025
Solved

clang-tidy fails to process project

  • November 7, 2025
  • 1 reply
  • 301 views

I was able to successfully build a TouchGFX demo project for a development board with clang+cmake using STM32CubeMX and STM32Cube plugin for VSCode. Although it required tweaking as it didn't work out of the box.
Before ST officially supported clang I was able to build a simple blinky project using clang for arm and cmake and then analyze the code using clang-tidy. Now I want to use clang-tidy on the project, but I get several errors

If I use clang-tidy from clang 1.19.5 I get the following issues:

PS C:\LLVM_19.1.5\bin> ./clang-tidy.exe -p C:\TouchGFXProjects\MyApplication_24\build\Debug C:\TouchGFXProjects\MyApplication_24\Core\Src\main.c
21 errors generated.
Error while processing C:\TouchGFXProjects\MyApplication_24\Core\Src\main.c.
error: too many errors emitted, stopping now [clang-diagnostic-error]
error: unknown argument: '--multi-lib-config=C:\ST\STM32CubeCLT_1.19.0\st-arm-clang/multilib.gnu_tools_for_stm32.yaml' [clang-diagnostic-error]
C:/TouchGFXProjects/MyApplication_24/cmake/stm32cubemx/../../Drivers/CMSIS/Include\cmsis_compiler.h:278:4: error: Unknown compiler. [clang-diagnostic-error]
278 | #error Unknown compiler.
| ^
C:/TouchGFXProjects/MyApplication_24/cmake/stm32cubemx/../../Drivers/CMSIS/Include\core_cm7.h:1871:1: error: unknown type name '__STATIC_INLINE' [clang-diagnostic-error]
1871 | __STATIC_INLINE void __NVIC_SetPriorityGrouping(uint32_t PriorityGroup)

Same for C:\LLVM_19.1.6 and C:\LLVM_21.1.4

And if I use starm-clang-tidy from ~\AppData\Local\stm32cube\bundles\st-arm-clang\19.1.6+st.9\bin:

.\starm-clang-tidy.exe -p C:\TouchGFXProjects\MyApplication_24\build\Debug C:\TouchGFXProjects\MyApplication_24\Core\Src\main.c
Error while processing C:/TouchGFXProjects/MyApplication_24/Core/Src/main.c.
error: unknown target triple 'unknown' [clang-diagnostic-error]
error: unsupported option '-mcpu=' for target '' [clang-diagnostic-error]
error: unsupported option '-mfloat-abi=' for target '' [clang-diagnostic-error]
error: unsupported option '-mfpu=' for target '' [clang-diagnostic-error]
warning: argument unused during compilation: '--gcc-toolchain=C:\ST\STM32CubeCLT_1.19.0\GNU-tools-for-STM32\bin/..' [clang-diagnostic-unused-command-line-argument]
warning: argument unused during compilation: '--multi-lib-config=C:\ST\STM32CubeCLT_1.19.0\st-arm-clang/multilib.gnu_tools_for_stm32.yaml' [clang-diagnostic-unused-command-line-argument]
Found compiler error(s).

And the same for clang-tidy from C:\ST\STM32CubeCLT_1.19.0\st-arm-clang\bin

Strangely I could not find the release of clang for arm 19.1.6 on github.  https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm/tags What version does ST base it on?

 

Reference: https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/help-with-building-stm32h735-demo-project-with-clang/m-p/853892

Best answer by unsigned_char_array

I had to change the following lines in cmake\starm-clang.cmake:

#set(STARM_TOOLCHAIN_CONFIG "STARM_HYBRID")
set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")

# set(TARGET_FLAGS "-mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")
set(TARGET_FLAGS "--target=thumbv7em-st-none-eabihf -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")

I had already copied the linker file that STM32CubeMX generated prior to switching to clang. Because only that one contained the correct memory regions (external RAM and Flash) for TouchGFX.

The STARM_HYBRID toolchain uses GCC linker and STARM_NEWLIB toolchain uses clang linker. Clang linker doesn't understand the linker file:

[build] ld.lld: error: C:/TouchGFXProjects/MyApplication_24/STM32H735XG_FLASH.ld:35: memory region not defined: RAM_D1
[build] >>> _estack = ORIGIN(RAM_D1) + LENGTH(RAM_D1); /* end of "RAM_D1" Ram type memory */

 I had to move the _estack line after the memory region definition:

_Min_Heap_Size = 0x1000; /* required amount of heap */
_Min_Stack_Size = 0x1000; /* required amount of stack */

/* Memories definition */
MEMORY
{
...
}
_estack = ORIGIN(RAM_D1) + LENGTH(RAM_D1); /* end of "RAM_D1" Ram type memory */

And now it builds (compiles and links). Also flashes with STM32CubeProgrammer. But the goal of this topic was to get clang-tidy to work and that succeeded. 

I had similar issues with the linker file before: https://community.st.com/t5/stm32cubemx-mcus/sysmem-c-build-error-in-clang/td-p/775105

1 reply

unsigned_char_arrayAuthorBest answer
Lead II
November 11, 2025

I had to change the following lines in cmake\starm-clang.cmake:

#set(STARM_TOOLCHAIN_CONFIG "STARM_HYBRID")
set(STARM_TOOLCHAIN_CONFIG "STARM_NEWLIB")

# set(TARGET_FLAGS "-mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")
set(TARGET_FLAGS "--target=thumbv7em-st-none-eabihf -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard ${TOOLCHAIN_MULTILIBS}")

I had already copied the linker file that STM32CubeMX generated prior to switching to clang. Because only that one contained the correct memory regions (external RAM and Flash) for TouchGFX.

The STARM_HYBRID toolchain uses GCC linker and STARM_NEWLIB toolchain uses clang linker. Clang linker doesn't understand the linker file:

[build] ld.lld: error: C:/TouchGFXProjects/MyApplication_24/STM32H735XG_FLASH.ld:35: memory region not defined: RAM_D1
[build] >>> _estack = ORIGIN(RAM_D1) + LENGTH(RAM_D1); /* end of "RAM_D1" Ram type memory */

 I had to move the _estack line after the memory region definition:

_Min_Heap_Size = 0x1000; /* required amount of heap */
_Min_Stack_Size = 0x1000; /* required amount of stack */

/* Memories definition */
MEMORY
{
...
}
_estack = ORIGIN(RAM_D1) + LENGTH(RAM_D1); /* end of "RAM_D1" Ram type memory */

And now it builds (compiles and links). Also flashes with STM32CubeProgrammer. But the goal of this topic was to get clang-tidy to work and that succeeded. 

I had similar issues with the linker file before: https://community.st.com/t5/stm32cubemx-mcus/sysmem-c-build-error-in-clang/td-p/775105

"Kudo posts if you have the same problem and kudo replies if the solution works.Click ""Accept as Solution"" if a reply solved your problem. If no solution was posted please answer with your own."
GCsor
Graduate
February 4, 2026

Thank you, I was also tiring to set up clang-tidy!

Adding the --target option helped. But I still get errors about missing system includes. If I use the starm-clang-tidy those are not present. Unfortunately the latest CubeCLT does not include the starm-clang-tidy anymore. Any ideas how to fix these include errors? I would not add the system include paths manually.

Lead II
February 4, 2026

@GCsor wrote:

Thank you, I was also tiring to set up clang-tidy!

Adding the --target option helped. 


Great to hear.

 


@GCsor wrote:

But I still get errors about missing system includes. If I use the starm-clang-tidy those are not present. Unfortunately the latest CubeCLT does not include the starm-clang-tidy anymore. Any ideas how to fix these include errors? I would not add the system include paths manually.


What includes?
CubeCLT is based on the ARM clang compiler. So you can install clang arm compiler with the same version and use clang-tidy from that. 

"Kudo posts if you have the same problem and kudo replies if the solution works.Click ""Accept as Solution"" if a reply solved your problem. If no solution was posted please answer with your own."