STM32H5 Upload and Debug Support

Hey all, user of PIO for a while now, but my first time needing to add support for a new micro from “scratch”, the STM32H5 (specifically an STM32H573). I’ve been working through some issues getting to compilation with the folks in the ST-STM32 Platform GitHub repo (STM32H5 Support? · Issue #758 · platformio/platform-ststm32 · GitHub).

I can get the code to compile, and debugging via an ST-Link V2 using STM32CubeIDE works well, so the hardware has been validated, however, I’m having trouble jumping through the hoops to get upload/debug happening.

The first problem was no stm32h5x.cfg file, which I downloaded from the STM32 OpenOCD repo, added to the appropriate tools-openocd folder.

I now am seeing this issue:

Uploading .pio\build\bridge8-v2-x-0\bridge8_v2.0.0.0-beta.49.elf
xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty (2023-01-30-15:04)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

hla_swd
Error: The selected transport doesn't support this target
C:\Users\samsp.platformio\packages\tool-openocd/openocd/scripts/target/stm32h5x.cfg:55: Error:
in procedure 'script'
at file "embedded:startup.tcl", line 28
at file "C:\Users\samsp.platformio\packages\tool-openocd/openocd/scripts/target/stm32h5x.cfg", line 55
*** [upload] Error 1

It seems as though something isn’t correctly configured in the .cfg file, but on the assumption that’s the same file that is being used within the STM32CubeIDE debug process, I’m not sure what to look for.

I also haven’t been sure about where to add the startup file generated by STM32Cube. Whilst I’ve had a lot of hands on time with STM32 micros, I haven’t gotten this into the weeds on adding debugger support yet and would appreciate some pointers.

ST-STM32 doesn’t currently support the STM32H5 series, so I’m flying blind a little here.

Oh no. The config file isn’t the only thing you’re missing, you need to have explicit support for it in the compiled binary. You should source the OpenODC binary from https://github.com/STMicroelectronics/OpenOCD/commits/openocd-cubeide-r6/. You either compile that yourself or copy it from an existing STM32CubeIDE installation on your computer and use it to overwrite the C:\Users\<user>\.platformio\tool-openocd\ files.

Thanks for the quick reply! That makes sense. Unfortunately still some issues. I wasn’t yet able to wrap my head around the process for locally building the STM32 fork of openOCD from source. I did find quite a useful ST forum reply with someone sharing their precompiled binaries with support for the STM32H5 (ねむいさんのぶろぐ | Project Examples and Misc Files), however I may be a little unclear about what needs to be replaced from the native OpenOCD package.

I was under the assumption that I needed to replace the .exe, and the target, interface etc… script folders. After doing that, I simply get an unknown error (presumably from OpenOCD) which doesn’t yield any useful results at all from their docs or googling. Could you shed some light on exactly should be done to facilitate this, I’ve spent several days down the rabbit hole on this one.

When I create a STM32H5 project with STM32CubeMX and open it in the STM32CubeIDE, the config shows how it uses OpenOCD very clearly.

All the needed paths for the various OpenOCD bits are there, you just have to create a new package in the same folder structure as the existing tool-openocd. I’ve done so at e.g. https://github.com/maxgerhardt/pio-openocd-stm32 for Windows.

Adding

platform_packages =
   tool-openocd@https://github.com/maxgerhardt/pio-openocd-stm32/archive/refs/heads/main.zip

to the platformio.ini should make PlatformIO use that version.

If your board JSON has the right OpenOCD settings, it should startup. For example, with openocd_target as stm32h5 should try to startup, but the STM32CubeIDE also generates a more high level board config, which I’ve too uploaded as stm32h573_generic.cfg and that can be referenced as openocd_board.

That is incredibly helpful! I’ll document a couple of the issues I was having in case others run into this:

  1. (just a silly me, sleep deprived mistake): My CubeIDE installation was quite old (1.8.0) and was only showing support (without specifically going and installing the plugins) for debug via GDB server, which is why it was a little confusing to find/use it’s local OpenOCD build.

I tried copying both my local build from CubeIDE, and also your platform_package suggestion and was getting stuck with this error:

DEPRECATED! use 'swj_newdap' not 'hla newtap'
DEPRECATED! use 'swj_newdap' not 'hla newtap'
embedded:startup.tcl:1360: Error: Infinite eval recursion
in procedure 'script' 
at file "embedded:startup.tcl", line 28
in procedure 'swj_newdap' called at file "C:\Users\samsp\.platformio\packages\tool-openocd/openocd/scripts/target/stm32h5x.cfg", line 72
in procedure 'hla newtap' called at file "C:\Users\samsp\.platformio\packages\tool-openocd/openocd/scripts/target/swj-dp.tcl", line 28

It was recursive and repeated the same error dozens of times before quitting.
What worked in the end was your suggestion of the openocd_board reference in my board.json file. Successful upload and debugging confirmed.
Thank you very much for your patience helping with this issues, it is much appreciated. It would be great if ST-STM32 enabled built-in support for the H5, and also the PIO chain with debugging, but at least I’m able to proceed with some board bring up and testing. Please let me know if I can help with any feedback on future integration with this series.

Thank you both for this thread. It worked for me as well for the STM32U083.

I am having an issue of sorts with this approach, though. The tool-openocd installed in this way overwrites the default tool-openocd, and all projects try to use the same one. It seems platformIO maintains separate versions only when a version number is specified, and not when a file:// or git:// url is specified.

The way I’ve worked around it for now is to specify the openocd version in platform_packages explicitly on all the other projects using the regular openocd, which to me feels like a recipe for disaster.

I did try to rename the package to tool-openocd-stm32, since there appear to be a number of such platform-specific openocd packages in the platformio repository. However, when I do that, platformIO does install tool-openocd-stm32 when specified in platform_packages but still tries to use the default openocd (tool-openocd).