Help with building/flashing STM32H735 demo project with clang

[unsigned_char_array]

I have a custom board with a STM32H735 and I have several issues with it building with clang and TouchGFX 4.26 for vscode. It works fine with 4.25 and GCC. I'm putting this migration on hold for now as many of these tools are still experimental.

What I now want is to first get a demo project working on the STM32H735G-DK board in vscode with cmake and clang.
I tried it this way:

1. in TouchGFX Designer 4.26 I select my board and select Dynamic Graph example. This builds and runs in Designer. 
2. I open the IOC file in STM32CubeMX V6.15.0 and change toolchain to CMake+Clang
3. I build in VScode using STM32Cube plugin (pre-release)
4. I get build errors

[main] Building folder: C:/TouchGFXProjects/MyApplication_24/build/Debug 
[build] Starting build
[driver] NOTE: You are building with preset Debug, but there are some overrides being applied from your VS Code settings.
[proc] Executing command: chcp
[proc] Executing command: cube-cmake --build C:/TouchGFXProjects/MyApplication_24/build/Debug --
[build] [1/132] Building C object CMakeFiles/STM32H735G-DK.dir/LIBJPEG/App/libjpeg.c.obj
...
[build] C:/TouchGFXProjects/MyApplication_24/Core/Src/main.c:545:23: warning: unused variable 'ospi_ram_init' [-Wunused-variable]
[build] 545 | BSP_OSPI_RAM_Init_t ospi_ram_init;
...
[build] C:\ST\STM32CubeCLT_1.19.0\GNU-tools-for-STM32\bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld: STM32H735G-DK.elf section `TouchGFX_Framebuffer' will not fit in region `DTCMRAM'
[build] C:\ST\STM32CubeCLT_1.19.0\GNU-tools-for-STM32\bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld: STM32H735G-DK.elf section `TouchGFX_Framebuffer' will not fit in region `FLASH'
[build] C:\ST\STM32CubeCLT_1.19.0\GNU-tools-for-STM32\bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld: region `DTCMRAM' overflowed by 1542024 bytes
[build] C:\ST\STM32CubeCLT_1.19.0\GNU-tools-for-STM32\bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 1256628 bytes
[build] Memory region         Used Size  Region Size  %age Used
[build]          DTCMRAM:     1673096 B       128 KB    1276.47%
[build]           RAM_D1:           0 B       320 KB      0.00%
[build]           RAM_D2:           0 B        32 KB      0.00%
[build]           RAM_D3:           0 B        16 KB      0.00%
[build]          ITCMRAM:           0 B        64 KB      0.00%
[build]            FLASH:     2305204 B         1 MB    219.84%
[build] starm-clang++: error: ld command failed with exit code 1 (use -v to see invocation)

Obviously one problem is the linker file here. I will try to merge this with the GCC linker file. It also seems ospi-ram is not used.

I've also tried to make the project starting from STM32CubeMX V6.15.0, but by default TouchGFX and all the needed peripherals are not configured. It's too much work to get it working from MX.

Why doesn't it work out of the box? Or am I doing something wrong?

UPDATE:

I've copied the linker file from the STM32CubeIDE project and now it builds. But I cannot flash/debug in vscode. I can only flash it from STM32CubeProgrammer.

[unsigned_char_array]

After copying the linker file from the unmodified STM32CubeIDE project to the clang project the build worked, but flashing/debugging failed. I had to add the following to launch.json to get debugging working. I switched to a different vscode profile, since the ST plugin doesn't work with cortex-debug.

        {
            "cwd": "${workspaceRoot}",
            "executable": "./build/Debug/STM32H735G-DK.elf",
            "name": "Debug with STLINK",
            "request": "launch",
            "type": "cortex-debug",
            "showDevDebugOutput": "raw",      
            "servertype": "stlink",
            "serverArgs": [
            "--extload", "C:\\ST\\STM32CubeCLT_1.19.0\\STM32CubeProgrammer\\bin\\ExternalLoader\\MX25LM51245G_STM32H735G-DK.stldr"         
            ],           
            "windows": {
            "serverpath": "C:/ST/STM32CubeCLT_1.19.0/STLink-gdb-server/bin/ST-LINK_gdbserver.exe",
            "stm32cubeprogrammer": "C:/ST/STM32CubeCLT_1.19.0/STM32CubeProgrammer/bin",
            "svdFile": "C:/ST/STM32CubeCLT_1.19.0/STMicroelectronics_CMSIS_SVD/STM32H735.svd"
            },       
            "runToEntryPoint": "main",  
        }

Now I'm having issues with clang-tidy. 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 clang-tidy from stm32cube\bundles\st-arm-clang\19.1.6+st.9:

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

In summary these are the issues.:

• vscode + clang + cmake does not work out of the box with TouchGFX
• it requires modification of the linker file after converting it with STM32CubeMX
• debug/flashing doesn't work with STM32Cube plugin, it does work with cortex-debug plugin with a custom launch.json file. Since that is incompatible with the plugin it will require using VSCode profiles.
• clang-tidy doesn't work on the code

[mathiasmarkussen]

The linker file issue is known and described in the TouchGFX documentation:

CMake as build system | TouchGFX Documentation

Regarding your tools issues, I believe you will get more qualified answers in the appropriate section of the forum.

[unsigned_char_array]

is this the appropriate section: STM32CubeIDE for Visual Studio Code (MCUs)?

Update:
I've create a new topic here to address the clang-tidy issue: https://community.st.com/t5/stm32cubeide-for-visual-studio/clang-tidy-fails-to-process-project/td-p/854286

Update2:
Clang-tidy now works. On the project.

The remaining issues are now:

• vscode + clang + cmake does not work out of the box with TouchGFX
• it requires modification of the linker file after converting it with STM32CubeMX
• debug/flashing doesn't work with STM32Cube plugin, it does work with cortex-debug plugin with a custom launch.json file. Since that is incompatible with the plugin it will require using VSCode profiles.

If I try to debug using the plugin I get this:

STMicroelectronics ST-LINK GDB server. Version 7.11.0
Copyright (c) 2025, STMicroelectronics. All rights reserved.

Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled

Waiting for debugger connection...
GNU gdb (GNU Tools for STM32 13.3.rel1.20250523-0900) 14.2.90.20240526-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
add-symbol-file "C:/TouchGFXProjects/MyApplication_24/build/Debug/STM32H735G-DK.elf" 
add symbol table from file "C:/TouchGFXProjects/MyApplication_24/build/Debug/STM32H735G-DK.elf"
(y or n) [answered Y; input not from terminal]
Reading symbols from C:/TouchGFXProjects/MyApplication_24/build/Debug/STM32H735G-DK.elf...
Debugger connected
Waiting for debugger connection...
Reset_Handler () at C:/TouchGFXProjects/MyApplication_24/startup_stm32h735xx.s:61
61 ldr sp, =_estack /* set stack pointer */
connected to remote target localhost:61234
Note: automatically using hardware breakpoints for read-only addresses.
load "C:/TouchGFXProjects/MyApplication_24/build/Debug/STM32H735G-DK.elf" 
Loading section TouchGFX_ScratchbufferA, size 0x100 lma 0x24000a20
Loading section TouchGFX_ScratchbufferB, size 0x100 lma 0x24000b20
Loading section ._user_heap_stack, size 0x2004 lma 0x24018794
Loading section ExtFlashSection, size 0x68230 lma 0x90000000
Load failed
cube is killed by signal SIGTERM

I suspect this is because it doesn't load the flash loader for external flash. I don't know how to add this.