[OpenOCD-user] Debugging fails on STM32G0xx with OpenOcd 0.12.0-x

[Mats K. <mat...@pr...>]

Hello,

We are moving into the newer family of ST devices, STM32G070/71 and STM33G0B0/B1

We are examining with the nucleo boards proved by ST.
Environment is windows11, arm-gnu-toolchain 2015q3 later 12.3 release, xpack OpenOcd 0.12.0-2 and Eclipse 2023.09.

OpenOcd connects fine and programs the device correctly via telnet interface, all tcl telnet access is ok.
Debugging with gdb seems ok at first look, stepping from reset vector and onwards.

Starting and stopping is fine and simple blink program runs ok.

However, no regular breakpoints hit. The default debugger breakpoint at main misses.
I need to set hardware breakpoints to pause the program at specific location. Breaks ok in IRQ and regular code.
Stepping in and out of functions fails in terms of debugging, the program enters run until a hardware breakpoint, if present, hits at correct location.

Same program and situation is tried on other nucleo boards, for example nucleo32 STM32G431, nucleo64 STM32F091 with no flaws in debugging.
Same program is tested with other environmental configurations, older versions of eclipse, and toolchain. I have not tried Linux or windows10.
Same program is tested in STM32CubeIDE with the default debugger, stlinkserver, without problems.
I found the OpenOCD delivery in STM32CubeIDE and got it started for STM32G0xx and the debugging problems are still there.

Since I have tested different combinations of the environment, toolchain and the fact that stlinkserver works it looks like an OpenOcd issue or a configuration issue that I have missed.

When looking through the OpenOcd issues and mailforums I have not seen any comment regarding a similar issue, which worries me since I doubt that the support for the devices would be released with such a flaw.

Has this behaviour been seen in any other combination or by anyone else?
Is there anything that strikes about this newer family regarding configuration and setup for debugging? I know it is similar to the STM32L family and our work on these devices is ok, I have not yet tested the same situation on this.
Please advice.

Regards
Mats Koponen