STM32G431RB (custom board) - DEV_TARGET_HELD_UNDER_RESET with all ST-LINK probes, worked previously

[krushna_moukthik]

I have a custom board using an STM32G431RB (LQFP64) that was previously programmable/debuggable without issue. After switching to a new ST-LINK debugger, I started consistently getting:

Error: ST-LINK error (DEV_TARGET_HELD_UNDER_RESET)

Root cause identified: the board was being powered entirely from the debugger's VDD/VTref pin rather than an independent supply. Powering the board from an external bench supply (debugger providing only SWDIO/SWCLK/GND, not VDD) resolves the connection issue. My working theory is that the ST-LINK's VDD/VTref pin is intended as a voltage sense input, not a real power source, and different probe units/firmware versions apparently have inconsistent (often very limited) current-sourcing capability there — my original debugger happened to supply enough current for this board to stay stable; every replacement unit since (including confirmed-genuine ST-LINK/V2 and V3 probes) could not, leading to what looks like repeated brown-out resets rather than an actual stuck NRST line or board fault.

Confirming details that fit this theory:

• Failure was 100% consistent across 3 different ST-LINK probes and even a second, different board — pointing away from a probe-specific or board-specific fault and toward something common to the setup (power)
• Target voltage still read correctly (~3.05–3.06V) in the ST-LINK config panel even during failures, but this reflects a sense reading, not confirmation of a stable supply under load
• Hot Plug mode occasionally succeeded in reading Device ID (0x468) before failing on deeper operations (option byte read, mass erase, flash read) — consistent with power sagging further under the additional current draw those operations require
• Deliberately shorting NRST to GND produced a distinctly different error ("Unable to get core ID" / "No STM32 target found") than the DEV_TARGET_HELD_UNDER_RESET seen under normal failure conditions, suggesting the normal failure wasn't a literal, continuous NRST-to-GND condition, consistent with a brown-out/reset-controller-driven state instead

Remaining question: While troubleshooting before identifying the power issue, I found the Option Bytes panel shows NRST_MODE = 0, which per RM0440 is a reserved/undocumented value (default should be 3, Reset Input + Output). Several attempts to correct this (GUI and CLI, -ob NRST_MODE=3, various connect modes) were made while the board was still being debugger-powered and unstable, so I'm not certain whether this write ever completed successfully. Now that stable external power resolves the connection:

1. Is NRST_MODE=0 expected to cause any issues on its own, given it's a reserved value?
2. Also seeing an intermittent CubeProgrammer database message: "There's no active configuration for this device. All the 3 configurations are disabled!" on this chip (Device ID 0x468) — is this a known cosmetic issue, and is there an updated device database available?

Setup details:

• MCU: STM32G431RB, LQFP64
• STM32CubeProgrammer v2.20.0, Windows 11 64-bit
• ST-LINK probes tested: multiple units (firmware V2J37S7, V2J48S7, V2J41S7)
• No external reset circuit on the board, no BOOT0 broken out, no UART/USB bootloader access
• Board now powered independently via bench supply; debugger provides SWD signals only

[Andrew Neil]

My working theory is that the ST-LINK's VDD/VTref pin is intended as a voltage sense input, not a real power source

Yes, that is correct; eg, from the ST-Link V2 User Manual:

 

ST-LINK probes tested: multiple units

What models ?

Are you sure they are genuine?

 

[krushna_moukthik]

HI @Andrew Neil 

We have pin 19 connected to power up the board. I have confirmed that the Debuggers are genuine. So, the MCU on the custom board should be getting required power. ca you please let me know if anything can be done to fix my issue.

Have a nice day.

Thank You.
 

[Mike_ST]

Hello,

» 1. Is NRST_MODE=0 expected to cause any issues on its own, given it's a reserved value?

From RM440/5.4.1 Option bytes description, NRST_MODE=0 is not described as reserved value, it is only flagged as reserved in STM32CubeProgrammer for some reason, and the STM32G431 comes with NRST_MODE=3 out of the box:

User and read protection option bytes
Flash memory address: 0x1FFF 7800
ST production value: 0xFFEF F8AA

Bits 29:28 NRST_MODE: PG10 pad mode
00: Reset Input/Output 
01: Reset Input only
10: GPIO
11: Reset Input/Output 

 

»  2. Also seeing an intermittent CubeProgrammer database message: "There's no active configuration for this device. All the 3 configurations are disabled!" on this chip (Device ID 0x468) — is this a known cosmetic issue, and is there an updated device database available?

Never seen that message for STM32G431, try reinstalling the latest STM32CubeProgrammer, and make sure you have a guenuine ST-link debugger.

 

 

 

[ahsrabrifat]

One wiring detail: with external power, the probe’s VTref/VAPP input should still connect to the target’s VDD, alongside SWDIO, SWCLK and GND. It lets the probe sense the target supply. Connecting NRST also enables hardware reset control.

Also, VDD and VTref aren’t interchangeable labels on every probe. On the genuine ST-LINK/V2’s 20-pin connector, pins 1/2 are VAPP; pin 19 is labelled 3.3 V VDD, but ST specifies leaving it unconnected to the target. See UM1075, Table 4. That distinction matters when explaining why the original setup worked.

For NRST_MODE=0, Mike_ST has clarified in this thread that both 00 and 11 select reset input/output, with 11 being the production default. That contradicts CubeProgrammer’s “reserved” label, so I wouldn’t keep rewriting option bytes just to clear that label. First save a fresh option-byte read with stable power. ST’s clarification

The database message has appeared in another STM32G431 report using CubeProgrammer 2.19 over UART, which ST acknowledged. That doesn’t establish the same cause here or prove it’s cosmetic. Try a fresh current CubeProgrammer installation, then provide the full connection log if it persists.

For a future board revision, bringing out a standard debug connector would make this easier. This PCBWay JTAG/SWD adapter project is a connector-format example; verify its pin mapping against your probe. Once the connection is reliable, TEP’s basic CubeIDE project walkthrough provides a simple firmware baseline, although it doesn’t address the G431 option-byte issue.