2025-11-17 2:41 PM
Hi everyone. I’m trying to connect a genuine ST-Link V2 to an AT32F415 MCU using SWD, but the debugger always reports “Target not detected” and shows Device Update: false.
Here’s my setup:
• SWDIO → SWDIO
• SWCLK → SWCLK
• GND → GND
• 3.3V from the board is present (measured ~3.29V)
• NRST is connected
• Target is externally powered
• Several different ST-Link drivers tested
• STM32CubeProgrammer, OpenOCD, and ReFlasher all fail to detect the device
• Different cables and different USB ports tested
My questions:
Does ST-Link V2 fully support SWD communication with AT32 (Artery) MCUs, or do I need an AT-Link?
If ST-Link V2 should work, what settings or wiring should I double-check?
Is there any special sequence needed to connect if the AT32 has read protection enabled?
Can ST-Link V2 connect to a target that is running firmware which may have disabled SWD pins?
Any insight or experience with ST-Link + AT32 would be appreciated. Thank you.
Solved! Go to Solution.
2025-11-24 2:56 PM
Hey Peter,
I appreciate the explanation. I just wanted to clarify one point from the technical side. The ST-LINK/V2 itself is really just a USB-to-SWD interface. It doesn’t have any built-in knowledge of specific microcontrollers — it simply pushes SWD clock and data down the lines. The restrictions come from ST’s own software, not from the hardware.
SWD is an ARM-standard debug protocol, so any ARM-based chip that implements it properly can be accessed through whatever tool can speak SWD. ST’s official programs won’t talk to Artery parts, but tools like OpenOCD or Artery’s own programmer use the ST-LINK just fine as the transport layer. The dongle isn’t discriminating; it’s the software stack on top that decides whether a chip is “recognized.”
So in practical terms, an ST-LINK/V2 can interact with an AT32 — you just need software that understands the AT32’s IDs and memory map. I’ve had no issues connecting through the right tools.
Just wanted to share that perspective. Thanks again for the information.
Best regards,
Owen
2025-11-17 3:12 PM
Welcome @Riskybiscuits, to the community!
If it is an original ST-LINK/V2 (see also this Knowledge base article), then it can only work with original STM32 from STMicroelectronics. For 32-bit MCUs from another manufacturer, you would need to use their tools, including debuggers, as STMicroelectronics does not recognise this manufacturer's MCUs and therefore cannot support them.
Good luck!
Regards
/Peter
2025-11-18 12:54 AM
@Riskybiscuits wrote:
Does ST-Link V2 fully support SWD communication with AT32 (Artery) MCUs
As @Peter BENSCH said, the ST-Link is only supported for use with ST's own products. It is not designed nor supported for use with any 3rd-party MCUs.
Similarly for ST's software tools - CubeIDE, CubeProgrammer, etc ...
@Riskybiscuits wrote:or do I need an AT-Link?.
Not necessarily - there are 3rd-party debug probes which do support a wide range of MCU families; eg, Segger J-Link...
2025-11-24 2:56 PM
Hey Peter,
I appreciate the explanation. I just wanted to clarify one point from the technical side. The ST-LINK/V2 itself is really just a USB-to-SWD interface. It doesn’t have any built-in knowledge of specific microcontrollers — it simply pushes SWD clock and data down the lines. The restrictions come from ST’s own software, not from the hardware.
SWD is an ARM-standard debug protocol, so any ARM-based chip that implements it properly can be accessed through whatever tool can speak SWD. ST’s official programs won’t talk to Artery parts, but tools like OpenOCD or Artery’s own programmer use the ST-LINK just fine as the transport layer. The dongle isn’t discriminating; it’s the software stack on top that decides whether a chip is “recognized.”
So in practical terms, an ST-LINK/V2 can interact with an AT32 — you just need software that understands the AT32’s IDs and memory map. I’ve had no issues connecting through the right tools.
Just wanted to share that perspective. Thanks again for the information.
Best regards,
Owen