Is the STLINK-V3SET locked to only ST MCUs?

[Terry Greeniaus]

I have been using an STLINK-V3SET probe for many projects with free software such as OpenOCD, pyOCD, etc. These projects have all targeted STM32 MCUs. I wanted to also use the probe for a project that includes a TI MSP432 MCU, but the probe seems completely unable to connect to it. Obviously, I wouldn't expect ST tools to support this, but there are many non-ST tools that should be able to drive the probe and talk to the TI chip. Digging through the STLINK protocol and what the software is doing, it appears that the STLINK-V3SET is actually locked down to only be talk to ST MCUs.

Is this a known limitation/restriction of the STLINK-V3SET? I have not been able to find many examples in Google of people even trying to use a V3/V3SET to talk to a non-ST MCU, although I have found one example of someone that says V2.1 works with non-ST MCUs while V3 doesn't.

Any clarification on this would be much appreciated.

[Ozone]

Didn't try that with a V3.

But it worked with a V2 STLink, I successfully flashed and debugged a NXP Cortex M3. But that was some while ago.

The greater problem is, you need a toolchain that supports both the STLink and Cortex M devices from different manufacturers.

OTOH, Segger provides a J-Link firmware for STLink pods (at least they did for V2) that is supported by most toolchains - in difference to STLink.

[Uwe Bonnes]

Stlink3 only works with STM devices and also fails to hot-plug connect to STM32 devices in some situations where other debuggers succeed to connect.

[Andreas Bolsch · Accepted solution]

See discussion and possible resolution at https://sourceforge.net/p/openocd/tickets/275/

[Uwe Bonnes]

There is also an effort to use reflash StlnkV3 as bl*ckm*g*ic debugger. I have the bootloader running and shopov the BMP application. Much works, more work needs to be done.

[Terry Greeniaus]

That explains a lot, including why I can't attach when the MCU is asleep in a WFI instruction while the DBGMCU clock enable bits are cleared. It's very disappointing that ST would lock their probes like this.

[Terry Greeniaus]

That was a confusing reply I posted earlier. What I've seen with an MCU like the STM32G4 that has only a single AHB-AP through the Cortex-M core is that if the DBGMCU clock enable bits are cleared and the core asleep in a WFI instruction then the debug probe cannot access anything via the AP, including reading the DBGMCU_IDC register. If the STLINK-V3 series relies on reading that register to "lock" itself to ST products, then this explains why it would be unable to attach in sleep mode to a single-AP MCU like the G4.

However, with an MCU like the STM32H7, there is a dedicated APB-AP (AP2) for an external debugger that is usable even if one or both of the Cortex-M cores are asleep. Third-party debuggers, such as the XDS110 embedded on one of the TI MSP boards I have lying around, are able to access the DBGMCU via AP2, set the clock-enable bits and then attach to the Cortex cores as if the DBGMCU enable bits had been preconfigured at boot time all along. I suspect that the STLINK-V2.1 may also be able to do this if it doesn't "lock" itself first, but I don't have one to test with. The STLINK-V3 series, however, just gives NO_DEVICE_CONNECTED errors when trying to initialize APs if the H7 is in sleep mode, so presumably it unnecessarily locks itself out because the firmware isn't smart enough to try probing the DBGMCU_IDC via AP2 instead of AP0.

Again, it's disappointing that ST has chosen this route.