Bricked my Nucleo-L476RG onboard ST-LINK while messing with bare-metal? (Unable to get core ID) - Looking for insight or closure.
Hey everyone,
I'm posting this out of pure frustration after spending an entire day trying to wrap my head around a hardware/debug lockout on my Nucleo-L476RG board while learning bare-metal STM32 development. I'm hoping someone can explain what actually happened under the hood, because I feel like I'm losing my mind.
Here is the timeline of what went down:
I was experimenting with pure bare-metal code (no HAL). At one point, my code included a low-power instruction (wfi - Wait For Interrupt) or initialized early on a routine that locked the core or stopped it from servicing the debug interface. Immediately after flashing that build, OpenOCD completely lost connection.
OpenOCD / CubeProgrammer throws "Error: Unable to get core ID" and "No STM32 target found", even when trying connect under reset. The board is not fully dead. The bootloader in system memory is completely fine, and I can still successfully flash the chip via UART (stm32flash with BOOT0 pulled high). So, the MCU itself runs code fine when booted via system memory, but the onboard ST-LINK debug interface/firmware bridge completely refuses to communicate with the target MCU over the SWD lines.
Did some chatting with gemini, tried some things to get it back. 1: Flashing a clean binary / wiping flash via UART. 2: Connect under reset and Hot Plug modes in STM32CubeProgrammer. 3: Hard-resetting the board manually while plugging in USB to catch the core during boot. 4: Checking the physical jumpers (CN2 jumpers are intact, JP5 is on U5V).
Nothing brings the SWD channel back to life. The onboard ST-LINK detects via USB on the PC, but it throws a brick wall the second it tries to talk to the main STM32 chip.
Since I'm sick of jumping through hoops with a broken onboard debugger, I've sort of decided to order an independent external ST-LINK V2 clone for a few bucks, pull the CN2 jumpers on the Nucleo, and hook up SWCLK/SWDIO directly to bypass the onboard.
- How on earth can a standard bare-metal program permanently break the debug circuitry of a Nucleo board if I didn't explicitly remap PA13/PA14 (SWDIO/SWCLK)? Did I trigger a hardware latch-up or ESD/voltage spike?
- Has anyone else experienced an onboard ST-LINK effectively "commiting suicide" while keeping the main MCU functional via UART?
Any insights are appreciated. I'm ready to move on to an external programmer, but I'd love to know what actually went wrong technically.