Debugging H5 and/or H7 from within Arduino IDE: Can't get it to work

[memotronics]

I've been pulling my hair out over this... all I want to do is debug my code from within the Arduino IDE.

I tried this on my H523. After adding the section to boards.txt and adding a linker script, I can build/compile/upload no problem. When trying to debug though, I'm running into a bunch of issues. (Please note that debugging from CubeIDE works fine)

When trying to debug though, I'm ran into a few issues: The boards.txt entry that came with stm32duino was missing an entry for openocd.target, that was an easy fix. But it's also missing a .cfg file (I copied it from CubeIDE) and also missing gdb_helper.tcl (which is referenced in the .cfg file).

Now, when I start to debug, it is complaining that there is no flash-driver for the STM32H5x

I'm a complete noob to openocd but it seems that the openocd binary that ST uses in CubeIDE (where debugging works fine) is a customized version (that, presumably, knows how to flash H5 MCUs).

I'm about to switch to a H7 MCU (waiting for part), my question is: Am I also going to run into issues trying to debug from Arduino? To put it in a less optimistic way: Does debugging H5 and/or H7 MCUs from Arduino even work?

[fpiSTM]

Hi @memotronics

unfortunately the official openocd does not support the H5 that's why you can't use it and yes ST have a customized one supporting it...
Don't ask me why it is not upstream yet... I don't know nor understand.

H7 is supported.

Her the list of target support by the openocd delivered with the core:

ls .arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32
.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32c0x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32f0x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32f1x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32f2x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32f3x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32f4x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32f7x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32g0x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32g4x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32h7x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32h7x_dual_bank.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32l0.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32l0_dual_bank.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32l1.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32l1x_dual_bank.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32l4x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32l5x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32mp13x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32mp15x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32u0x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32u5x.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32w108xx.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32wbax.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32wbx.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32wlx.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32x5x_common.cfg

.arduino15/packages/STMicroelectronics/tools/xpack-openocd/0.12.0-6/openocd/scripts/target/stm32xl.cfg

When I need to debug unsupported one, I change the platform.txt to use the one from STM32Cube IDE like this:

Code: Select all

--------------------------------- platform.txt ---------------------------------
index ba2d29676..a5fe416e2 100644
@@ -17,7 +17,7 @@ busybox=
 busybox.windows={runtime.tools.STM32Tools.path}/win/busybox.exe
 
 toolchain_dir={runtime.tools.xpack-arm-none-eabi-gcc-14.2.1-1.1.path}
-openocd_dir={runtime.tools.xpack-openocd-0.12.0-6.path}
+openocd_dir=/local/ST/stm32cubeide_1.13.1/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.linux64_2.4.100.202501161620/tools/
 
 tools_bin_path.windows={runtime.tools.STM32Tools.path}/win
 tools_bin_path.macosx={runtime.tools.STM32Tools.path}/macosx
@@ -258,8 +258,8 @@ debug.toolchain.path={toolchain_dir}/bin
 debug.toolchain.prefix=arm-none-eabi
 debug.server=openocd
 debug.server.openocd.path={openocd_dir}/bin/openocd
-debug.server.openocd.scripts_dir={openocd_dir}/openocd/scripts
+debug.server.openocd.scripts_dir=/local/ST/stm32cubeide_1.13.1/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts
 # Common config
-debug.server.openocd.scripts.0=interface/stlink.cfg
+debug.server.openocd.scripts.0=interface/stlink-dap.cfg
 debug.server.openocd.scripts.1={runtime.platform.path}/debugger/select_dapdirect.cfg
 debug.server.openocd.scripts.2=target/{openocd.target}.cfg

But there is an bug in the Arduino IDE, it does not use the openocd.scripts_dir so I have open an issue on GitHub:

https://github.com/arduino/arduino-ide/issues/2746

To be able to debug, I launch the first time the debug (it fails) then edit the launch.json produced by Arudino to add:
"searchDir": ["/local/ST/stm32cubeide_1.13.1/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts"],

Finally, launch using the arrow in the Debug view not the button in the main bar else it will overwrite the launch.json.


Here the result with a Disco H573:

DKH573_dbg.png (94.83 KiB) Viewed 138 times

[fpiSTM]

One other way is to use cmake then launch your project thanks STM32CubeIDE.

[memotronics]

OK, I'm going to give Arduino another shot when the H7 board / CPU arrives.

I found a STM32H743VI board for $17 on Amazon. Wish me luck !

[fpiSTM]

No luck here. Just openocd issue... which can become a nightmare. Debug under Arduino IDE is very young and need some improvement.

[ag123]

OK, I'm going to give Arduino another shot when the H7 board / CPU arrives.

I found a STM32H743VI board for $17 on Amazon. Wish me luck !

is it the same as this one?
https://www.aliexpress.com/item/1005006632336183.html

if it is it may 'work out of the box' e.g. with the WeAct MiniSTM32H743VIT6 board
https://github.com/stm32duino/Arduino_C ... 2h7-boards
https://github.com/WeActStudio/MiniSTM32H7xx

a word ahead, h7 chips are (certainly) more advanced than the 'lower' series e.g. F3, F4, G4, L4, H5 - then F7, H7.
I fiind it 'more complicated' than say a stm32f401/f411, e.g. the system clocks (and to the pheripherals) are very different from most of the 'simplier' chips (except maybe h5), it seemed in the f7 , h7, the system clocks and peripheral clocks can run 'independently' of each other.
this is a 'big deal' because normally say on f3, f4, g4 etc, the peripheral clocks are divided down from the system clocks.
while in f7, h7, they can be different (e.g. independent), hence clock sources are more complex, but the extreme is that
(i think) it is possible to switch cpu frequency on the fly, and say if you are using SPI, that can stay at the same frequency/speed, even though you just swtched the cpu (system clock) frequency.

hence I added some 'experiments' and contributed:
https://github.com/stm32duino/Arduino_C ... x.cpp#L266

Code: Select all

/*
 * Power saving mode, mcu runs significantly cooler
 * Sysclock 240 Mhz, bus clocks 120 Mhz
 */
void SysClkHalfSpeed() { ...

https://github.com/stm32duino/Arduino_C ... x.cpp#L291

Code: Select all

/*
 * Full speed - sysclk from PLL1 P - 480 Mhz
 * Sysclock 480 Mhz, bus clocks 240 Mhz
 */
void SysClkFullSpeed()
{

Those are more 'convenience features', my goof I think is that I varied the APB (peripheral bus) speeds (I didn't check that too well).
That may change the downstream IO speeds, but I'm not sure, so if you want to play with those do check them.
(Actually, the intent is to reduce core temperatures, rather than simply switching speeds).

A thing is at 480Mhz, I think it runs a little too warm for my liking (like 50 deg C) doing 'nothing' (perhaps just blinking a led etc), well that is a 'big' chip, VVLSI.
Hence, I added that SysClkHalfSpeed(), and calling that reduce system clock to 240 Mhz down from 480 Mhz, it runs much 'cooler' (like 40-43 deg C) than if running at 'full speed' 480 Mhz. And I think while contributing that variant, I actually tried switching the speeds and it works at 'runtime'.
just that I did not check the IO stuff, hence, if it matters you may want to tweak it if you use those 2 calls.

a favourite thing I tend to try on these *big* chips is to run the Whetstone benchmark, this should be a pretty (very) fast chip with good Whetstone benchmarks
https://github.com/stm32duino/STM32Exam ... /Whetstone
accordingly, Arm Cortex M7 is a superscalar processor, different from the rest of the 'simpler' mcus.
https://developer.arm.com/Processors/Cortex-M7

while these 'big' chips looks like an 'overkill', these days with 3d printing firmware capable of doing physics based input shaping
https://marlinfw.org/docs/features/input_shaping.html
I may find a use for it there.