openocd: flashing the STM32C0 and other "new" boards

[crasbe]

Description

As discovered in #21775 (comment), the latest OpenOCD upstream code is required to flash the STM32C071 because the last OpenOCD Release (0.12.0, which is two years old at the time of writing) does not support is.

Also, the latest OpenOCD version wants the flash method to be swd instead of hla_swd, which apparently is not supported anymore.
swd is not a supported method for older OpenOCD versions though (0.11.0 that is standard on Ubuntu 22.04 LTS for example).

The make script that configures the OpenOCD settings for the ST-Link is not a great help at the moment because it changes swd to hla_swd by default:

RIOT/makefiles/tools/openocd-adapters/stlink.inc.mk

Lines 10 to 16 in 355e5f4

	# If swd / jtag is selected by the board, prefix it with hla_
	ifneq (,$(filter swd jtag,$(OPENOCD_TRANSPORT)))
	OPENOCD_TRANSPORT := hla_$(OPENOCD_TRANSPORT)
	endif
	# All ST-Link adapters support hla_swd, so use that for simplicity
	OPENOCD_TRANSPORT ?= hla_swd

One temporary fix would be to set the OPENOCD_TRANSPORT variable to dapdirect_swd, which is also deprecated though...

The better solution would be to add a version check.

@maribu said that Zephyr maintains it's own OpenOCD fork that supports all boards supported by Zephyr, so that might be an option to look at. Perhaps it also supports the RP2040 and RP2350, so we don't need to point to the Raspberry Pi fork of OpenOCD?

It would be nice not to have to have three or four different OpenOCD forks on the computer 🫠

[AnnsAnns]

I like the Zephyr idea if it works out 😄

[maribu]

We could rename the transport from swd to hla_swd within the openocd.cfg, as that is a TCL script that has access to the OpenOCD internals. We could ask upstream what if they suggest to better check for the OpenOCD version or if there is a simple test to check whether swd is valid, or only hla_swd.

[maribu]

OK, I just asked in IRC. The swd vs hla_swd is not because of different versions of OpenOCD, but because of different debug adapters. For ST-Link v2hla_swd should still be correct.

@crasbe: What adapter are you using with the STM32C0?

[maribu]

With regard to the ST-Link (v2): I got the recommendation to try not selecting a transport explicitly and just source interface/stlink.cfg instead. For the ST-Link, the interface script should select a suitable interface that is SWD on the wire by default.

[maribu]

OK, instead of further summarizing the IRC, I'll just drop a link to the log here https://libera.catirclogs.org/openocd/2025-10-10#

[maribu]

@crasbe: On which board did swd not work and you were forced to use hla_swd? Would updating the ST-Link firmware allow you to use swd?

[crasbe]

@crasbe: What adapter are you using with the STM32C0?

The built-in ST-Link/V2 of the Nucleo-C071RB.

@crasbe: On which board did swd not work and you were forced to use hla_swd? Would updating the ST-Link firmware allow you to use swd?

This is not an issue of the ST-Link, that works fine. Also it has the latest firmware, I checked that as well.

Here is a matrix of the OpenOCD behavior for various versions. The upstream version is Open On-Chip Debugger 0.12.0+dev-02228-ge5888bda3-dirty (2025-10-09-21:04), the Release version is Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64 (2025-10-10-19:33).

"works, doesn't support C0" means that it actually speaks with the microcontroller and then fails with this message:

Warn : Cannot identify target as an STM32G0/G4/L4/L4+/L5/U5/WB/WL family device.
Error: auto_probe failed

OpenOCD Version	OPENOCD_TRANSPORT=hla_swd	OPENOCD_TRANSPORT=swd	OPENOCD_TRANSPORT=dapdirect_swd	OPENOCD_TRANSPORT=
0.11.0	works, doesn't support C0	"adapter doesn't support"	"adapter doesn't support"	auto-selects hla_swd 1)
0.12.0 Release	works, doesn't support C0	"adapter doesn't support"	"adapter doesn't support"	auto-selected hla_swd 2)
0.12.0 upstream	"adapter doesn't support"	works	works, deprecation warning	auto-selects swd (dapdirect), deprecation warning 3)

1. Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. hla_swd
2. Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. hla_swd Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
3. Warn : DEPRECATED: auto-selecting transport "swd (dapdirect)". Use 'transport select swd' to suppress this message. swd (dapdirect)

[maribu]

OK, so bottom line from IRC is:

• We should stop to explicitly select a transport for now for the ST-Link v2 and rely on the implicitly selected transport to work across OpenCD versions
• We wait for a future release of OpenOCD withswd transport to hit Ubuntu LTS (our baseline of support). Then:
  • We explicitly select swd
  • The new transport may not work on older firmwares. So we add a hint to our doc that updating the ST-Link firmware is suggested.

Context: The default selection of a transport has been deprecated, as the default transport depends on the adapter used. Changing the adapter with the otherwise same script and board could result e.g. in using JTAG instead of SWD; which would be highly confusing.

[crasbe]

I like the Zephyr idea if it works out 😄

Perhaps not. The Zephyr fork seems to be still based on 0.11.0 and it does not support the STM32C0xx or RP2350: https://github.com/zephyrproject-rtos/openocd/tree/zephyr-20250213/tcl/target

So it's not worth dealing with that I guess.