STM32G431RB (custom board) - DEV_TARGET_HELD_UNDER_RESET with all ST-LINK probes, worked previously
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:
- Is NRST_MODE=0 expected to cause any issues on its own, given it's a reserved value?
- 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
