OpenOCD cannot configure TPIU/SWO on STM32H7

[thestumbler]

Tested ITM UART logging example but moved and modified for the H7, no joy. I get two error messages when I try running the SCONS command (found in these issue pages for starting viewing the stream).

(1) OpenOCD reports that stlink-v2.cfg has been deprecated, use stink.cfg. I edited that temporarily in the generated MODM file and that warning went away.

(2) There's another message that says ITM.TPIU doesn't support the UART protocol. I can't figure that one out, and it appears to be fatal.

There could be some issues on my side with the hardware and setup. I've only recently discovered ITM UART over SWO in the past couple months. I only had tested it briefly on a custom PCB that I designed using an off board STLink3 debugger. For viewing I demonstrated success using STM32Cube MX, Keil uVision, and on the command line using openOCD (my notes from that experiment are unclear). Also, I only briefly glanced at the schematics for the Nucleo H723 board to confirm that SWO was routed to the onboard STLink, I may have missed a jumper.

But even if I messed up on the configuration or the hardware connections, it seems to me I would just not get any data on the SWO viewer, not the "protocol not supported" messages.

I think I have a blue pill board somewhere in my lab. If so, I'll quickly test that this morning, just in case it's an H7-related thing.

EDIT:

I checked my version of OpenOCD, recalling the warning in the installation quick start guide. That seems to be up to date at version 0.12

I'm 99% sure my arm-none-eabi-xxxx tools are correct. But I admit I did not use the recommended XPACK method. I already had them installed from ARM using BREW. ARM changed access to the embedded tools awhile back and the best way to install them in 2023 is no longer clear to me.

What's the "native" environment the developers use day-to-day for their work? I wouldn't mind trying a Linux machine if that might make my life easier. Please don't say Windows

[salkinium]

It's not a modm problem, unfortunately it's an OpenOCD problem, it doesn't correctly set the registers for the STM32H7 debug peripherals, which are a more complete version of the Coresight implementation than on the STM32F7 for example. The extended Coresight is required for dual-core supported tracing etc.

There currently is no workaround from modm's side, at work I have the exact same issue (see emdbg), where I need the ITM over SWO and I have to use a JLink for it.

In theory it should be possible to set the values just from GDB, but I haven't managed to find the correct configuration yet.
The orbuculum project does it that way, but doesn't support H7 yet. I tried this gist too, but it didn't work for me either. I should really compare the registers before and after JLink configures them.

[salkinium]

I edited that temporarily in the generated MODM file and that warning went away.

We ought to fix that.

What's the "native" environment the developers use day-to-day for their work?

I use macOS 13 and my co-maintainers use a Linux distribution. Windows is only supported for completeness via the CI.

ARM changed access to the embedded tools awhile back and the best way to install them in 2023 is no longer clear to me.

This is the official one https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads.
You can install it via homebrew:

brew tap osx-cross/arm
brew install arm-gcc-bin@12

There's also a arm-none-eabi-gcc in the core homebrew repo, but it's missing newlib and several patches, making it useless. Not sure why it's in there at all tbh.

But I admit I did not use the recommended XPACK method.

Only matters if you want GDB with Python3 support for advanced plugins like in emdbg. Shouldn't be necessary for compilation.

[thestumbler]

The extended Coresight is required for dual-core supported tracing etc.

Does it make any difference that the two H7 flavors I am using (H723 and H735) are not dual core?

[salkinium]

Nope, it's using the same coresight system (I use H753 at work, also single core).

[salkinium]

I was able to enable the SWO using GDB scripting:

# 20MHz SWO clock
set $SPEED = 20000000

# DBGMCU_CR D3DBGCKEN D1DBGCKEN TRACECLKEN
set *0x5C001004 |= 0x00700000

# Unlock SWTF_LAR
set *0x5C004FB0 = 0xC5ACCE55
# Enable ITM input of SWO trace funnel SWFT_CTRL
set *0x5C004000 |= 0x00000001

# Unlock SWO_LAR
set *0x5C003FB0 = 0xC5ACCE55
# SWO current output divisor register
# SWO_CODR = (CPU/4 / SWO) - 1
set *0x5C003010 = ((480000000/4 / $SPEED) - 1)
# SWO selected pin protocol register SWO_SPPR
set *0x5C0030F0 = 0x00000002

This only configures the debug peripheral, you still need to set AF0 on PB3 (but that's handled by modm anyways) and also tell OpenOCD to start SWO sampling without configuring the debug peripheral (where it currently crashes).