STM32U5G7VJT6 – ST-LINK "Target no device found" despite correct SWD connections

Furkan2 · ‎2026-05-31

Hi

I am facing an issue while trying to connect to an STM32U5G7VJT6 using ST-LINK.

Target no device found
Error in initializing ST-LINK device.
Reason: No device found on target.

Hardware Details-
MCU: STM32U5G7VJT6
Debug Interface: SWD
SWDIO: PA13
SWCLK: PA14
Target Voltage: ~3.3V
BOOT0: Connected to GND
VCAP capacitor fitted (4.7 µF)
NRST connected to debugger header
Debug Connector-
The attached schematic shows the SWD/JTAG programming header connections.

Troubleshooting Already Performed-
Verified SWDIO (PA13) and SWCLK (PA14) continuity.
Verified target supply voltage is present.
Tried STM32CubeProgrammer with:
Normal mode
Under Reset mode
Hot Plug mode
Tried different reset modes (Software reset, Hardware reset, Core reset).
Reduced SWD frequency down to low values (100 kHz and below).
Updated ST-LINK firmware.
Referred to multiple ST Community posts with similar symptoms and tested suggested solutions.
Confirmed BOOT0 is low.(I did try high also)

Question

In this condition, is it possible that the STM32U5G7VJT6 has entered a state where the SWD interface is no longer accessible (device appears "locked" or unresponsive to the debugger)?
Can any firmware configuration, option bytes, low-power mode, clock configuration, or watchdog condition cause the device to stop responding to ST-LINK completely?
If the MCU is locked or stuck in such a state, what is the recommended recovery procedure?
Hardware reset sequence?
BOOT0 bootloader recovery?
Connect Under Reset mode?
STM32CubeProgrammer mass erase?
Any other recovery method specific to the STM32U5 series?
Is there any method to determine whether this is a hardware issue (power, reset, VCAP, PCB, soldering, etc.) or a software/firmware issue that has made the device inaccessible?
Any suggestions for diagnosing or recovering the MCU would be greatly appreciated.

THANKS

Ozone · ‎2026-06-01

In this condition, is it possible that the STM32U5G7VJT6 has entered a state where the SWD interface is no longer accessible (device appears "locked" or unresponsive to the debugger)?

One important information is missing in your post - do you talk about a commercial evaluation board, or a custom board ?

I have no experience with the U5 seies itself, so I cannot really comment on details.

You can check the ST-Link with another target, but I suppose it is fine.

If you talk about a custom board, are the BOOTx pins on a proper and defined level ?
If I remember correctly, you get no JTAG/SWD access when the MCU enters the ROM bootloader.

Is there any method to determine whether this is a hardware issue (power, reset, VCAP, PCB, soldering, etc.) or a software/firmware issue that has made the device inaccessible?

This suggests a custom board.
I would recommend to check supply voltages, SWD and BOOTx levels on the MCU pin directly, if possible.
And of course check the current consumption. This should be around the average for HSI default with all peripherals off (datasheet value), plus additional external components on the PCB.

Andrew Neil · ‎2026-06-01

As @Ozone said, what board is this ?

Please show your ST-Link connections; some good, clear photos of your setup would help.

How to write your question to maximize your chances to find a solution

What ST-Link are you using? Is it genuine?

How to recognize a genuine ST-LINK/V2 versus a cloned one

How to solve connection errors when connecting and programming the STM32 target board.

How to solve debugger connection issues

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Furkan2 · ‎2026-06-01

Thank you for the suggestions.

This is a custom board based on STM32U5G7VJT6.

I checked the following directly on the MCU pins:

* VDD = 3.2V
* VCAP = 0.9V
* NRST = 3.3V
* BOOT0 = Low

I also tried connecting with STM32CubeProgrammer using Under Reset mode (100 kHz), but I consistently get:

"Unable to get core ID"
"No STM32 target found"

The ST-LINK is functional and can communicate with other targets.

Before replacing the MCU, are there any additional checks you would recommend? I would like to treat MCU replacement as the last option.

Also, could you please clarify the expected behavior regarding BOOT0?

* If BOOT0 = Low and the user application is corrupted or causing issues, should the target still be detectable through SWD when using Under Reset mode?
* If BOOT0 = High, should the target always be detectable through SWD regardless of the application firmware?

In other words, if the device cannot be detected with either BOOT0 = Low or BOOT0 = High, would that generally indicate a hardware issue (SWD routing, soldering, PCB assembly, damaged MCU, etc.) rather than a firmware/software issue?

Any guidance on distinguishing hardware failure from firmware/security/debug-authentication related issues would be greatly appreciated.

Andrew Neil · ‎2026-06-01

You've marked the thread as solved, but it appears not to be?

To unmark it, see this.

@Furkan2 wrote:
This is a custom board based on STM32U5G7VJT6.

Then you need to post the schematic.

Has it ever worked?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

Furkan2 · ‎2026-06-01

The debugger is a genuine ST-LINK/V2. I have verified that the same ST-LINK can successfully connect to and program other STM32 targets.

I will share clear photos of:

The target board
SWD connector wiring
MCU area
ST-LINK connection setup

Ozone · ‎2026-06-01

> Before replacing the MCU, are there any additional checks you would recommend? I would like to treat MCU replacement as the last option.

I would want to confirm the PCB is correct before trying to replace the MCU. Another MCU on an incorrect PCB will almost certainly exhibit the same behavior.

> Also, could you please clarify the expected behavior regarding BOOT0?

This is usually documented in the reference manual, section "Boot configuration".
BOOT0 at Low usually means booting from Flash, which is probably what you want in this case. The other combinations (at least for the F0...F4 I use to deal with) select boot from system ROM, or from RAM.

> In other words, if the device cannot be detected with either BOOT0 = Low or BOOT0 = High, would that generally indicate a hardware issue (SWD routing, soldering, PCB assembly, damaged MCU, etc.) rather than a firmware/software issue?

There is no firmware in this stage (unless you ordered pre-programmed MCUs, which some vendors offer).On a proper PCB you should be able to connect nonetheless.
I have no experience with the U5 devices, and assume the security features the M33 architecture contains might complicate things ...

I would first check all relevent trace on the PCW with continuity tester (ohm-meter), for correct connection and for shorts to neighboring pins or e.g. Gnd. And second, apply power, check the current, and measure the static voltages on those pins.
If possible you can connect the ST-Link and and a scope, and verify you can see the SWD signals on the MCU pins.

AScha.3 · ‎2026-06-01

From pic , there seems to be a 5-pin chip on swd/swc lines : what is it ?

Maybe remove it, and check connection.

+

Can you try a st-link V3 ?

+

Is this the first/only board with this problem ? have another to check ?

If you feel a post has answered your question, please click "Accept as Solution".

Ozone · ‎2026-06-01

As an addendum, most debug pods check the VRef / VTref pin (+3.3V), to see if target is connected : https://www.segger.com/products/debug-probes/j-link/technology/interface-description/

AFAIK the STLink as well.