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 that other topic I created).

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.

I created a dedicated topic for this: https://community.st.com/t5/stm32cubeide-for-visual-studio/debugging-stm32h735g-dk-with-external-flash-fails/m-p/855988#M1481

update: Debugging now works. Solution is in that link.

[unsigned_char_array]

Since debugging now works I got everything to work. I also got it to work on several development boards. It's quite a hassle to setup everything. I think ST can improve it. I think the time of clang has come. One major advantage is you can write your own tools to analyze code (clang.cindex library in python or c++).
In summary here are my issues with the process:

1. vscode + clang + cmake does not work out of the box with TouchGFX. I think it should at least work with some development boards and demo projects.
2. it requires merging of the linker file after converting it with STM32CubeMX (sections are removed)
3. the default GCC linker file doesn't work with clang (needs to swap order of some statements), so you need the hybrid toolchain
4. for clang-tidy to work you need the clang toolchain so that requires the linker file to be modified (the linker file can be made compatible with both GCC and CLANG so ST can definitely improve this)
5. cmake file requires adding "--target=thumbv7em-st-none-eabihf" or clang-tidy doesn't recognize the CPU
6. STM32CubeMX deletes settings when upgrading firmware pack, you have to manually restore each setting (file diff tools help a lot here)
7. s file is moved to the root, so if you want to keep STM32CubeIDE builds working you need to point to the new one
8. linker file is also renamed. You can accidentally point to the wrong one. It makes version control also harder.
9. if your board has external flash you need to manually patch the launch file to include the stldr file (this should be done automatically in my opinion)

 

[mathiasmarkussen]

Hello,

I'll try to address this :)

1. 2, 3, 6, 8: We are working on this for TouchGFX Board Setups for the upcoming release of CubeMX 6.16. When using clang in that version, it uses picolib instead of hybrid toolchain by default. This has lead to us uopdating our TouchGFX projects to rely on the linker script that is generated for CMake for both our make-based run target solution and CubeIDE. So we will supply that file with the relevant modifications by default, and the CubeIDE project will also be configured to build using that. So no more modification of linker scripts or manually pointing to the one used for CubeIDE. as for 6 and 8, i certainly hope this will not be the case going forward. In any case, we will be reporting that as problems during our verification process of new CubeMX releases going forward, and would hopefully be fixed before release.

4, 5: I don't know if this will be solved by what I described above. I do not believe it is a graphics issue, but it may be resolved by us basing our code on the new generated linker scripts.

7: Are you sure the existing file for CubeMX is actually removed? In any case, TouchGFX designer only updates the project for the toolchain that is selected in CubeMX, so if you choose CMake as your toolchain, the CubeMX project will not be updated with the files you add to the TouchGFX project, so I guess this can be considered kind of unsupported anyway. In any case, CubeMX will not update the project either, so at least your modifications will not be undone. If you want CubeMX to include the file in the project on generation if you switch back and forth, you can add it in the .extsettings file.

9: I agree that this could be handled better. The optimal solution would be for the VS Code plugin to support boards as well as MCU's and generate a suitable launch.json, but again, that is not a graphics issue. We might start including a preset launch.json that works with our examples at some point, depending on internal prioritization.

 

[unsigned_char_array]

Great to hear.

5 is indeed not a graphis issue. We use clang-tidy to do analysis on our clang build. It is the reason we use clang. For some reason clang-tidy gets confused by the processor, but the compiler doesn't. 
Can you tell me more about ".extsettings"?