STM32H7A3LIH6Q — SWD permanently unresponsive after ~20 flash cycles, UART bootloader work

[mvo]

Device: STM32H7A3LIH6Q (TFBGA225) Tools: STM32CubeProgrammer v2.22, STLINK-V3MINIE, OpenOCD 0.12.0 IDE: STM32CubeIDE / HAL Custom PCB, 4 boards affected identically

---

Summary

After approximately 20 successful flash/debug cycles, all 4 of our custom boards became permanently unreachable via SWD. The MCU continues to run user code normally (UART/VCP output visible), VCAP voltage is nominal, but the ST-LINK cannot connect in any mode. The UART bootloader is functional and we can flash via UART. SWD remains dead even after mass erase with blank flash.

---

Hardware Configuration

• VLXSMPS connected via 2.2µH inductor to VDDLDO and VFBSMPS
• VCAP decoupling caps present
• NRST connected to STLINK-V3MINIE
• BOOT0 accessible and functional
• No USB connector on board

---

Root Cause Identified

Our firmware was using the wrong power supply configuration:

// Wrong — was in our code:
HAL_PWREx_ConfigSupply(PWR_SMPS_1V8_SUPPLIES_EXT_AND_LDO);

// Correct for our hardware topology:
HAL_PWREx_ConfigSupply(PWR_SMPS_1V8_SUPPLIES_LDO);

Our hardware is a standard SMPS-feeds-LDO topology (VLXSMPS → 2.2µH → VDDLDO). The EXT_AND_LDO setting sets SMPSEXTHP in PWR_CR3, which configures the SMPS for a high-power external load that does not exist on our PCB.

---

Observed Symptoms Progression

1. Board flashes and debugs perfectly for ~20 cycles
2. After ~20 cycles: ST-LINK suddenly cannot connect — Error: Unable to get core ID / No STM32 target found
3. User code continues running normally, UART output visible
4. All SWD recovery methods fail (Normal, Under Reset, Hot Plug, OpenOCD with all reset modes)
5. BOOT0 high + power cycle → ROM bootloader runs but SWD still fails
6. UART bootloader connects and works perfectly
7. Option bytes read via UART: RDP=0xAA (Level 0), no WRP, no PCROP
8. Mass erase performed via UART → blank flash → SWD still fails
9. VCAP = 0.9V with blank flash (correct VOS3 default)

---

What We Tried for Recovery

• STM32CubeProgrammer: Normal, Under Reset, Hot Plug modes
• All SWD frequencies from 5 kHz to 8 MHz
• OpenOCD with reset_config srst_only srst_nogate, reset_config none, adapter speed 480 kHz
• BOOT0 pulled HIGH + full power cycle (30+ second discharge)
• Multiple rapid power cycles with BOOT0 high per community suggestions
• UART bootloader: successful — confirmed chip ID 0x480, read option bytes, mass erase, reflash

---

Questions

1. Why does SWD remain permanently dead even after mass erase with blank flash, when the UART bootloader works perfectly?

This rules out software as the cause after erase. The DAP appears to be non-functional while the CPU core is completely healthy.

2. Can the PWR_SMPS_1V8_SUPPLIES_EXT_AND_LDO misconfiguration on SMPS-feeds-LDO hardware cause permanent damage to the internal DAP/debug port circuitry after repeated power cycles, even though ST documentation states the device can tolerate LDO+SMPS conflict without damage?

We observed VCAP at 1.3V during every user firmware boot cycle for ~20 cycles. The LDO output was elevated above nominal. Is there a known failure mode where the debug port is damaged while the CPU core survives?

3. Is there any known recovery path for a STM32H7A3 where the UART bootloader is functional but SWD/DAP is permanently unresponsive, short of chip replacement?

We have confirmed via UART: RDP=0xAA, no protection active, blank flash — and SWD still fails. We are not aware of any remaining software explanation.

4. Does the STM32H7A3 DAP have an independent power domain or supply path that could be damaged independently of the CPU core?

---

Additional Notes

• All 4 boards failed after approximately the same number of flash cycles (~20), strongly suggesting a deterministic stress mechanism rather than random hardware failure
• CubeMX .ioc was missing SYS.Debug=Serial_Wire entry — PA13 had no CubeMX protection (PA14 was locked, PA13 was not)
• ES0478 errata section 2.2.1 noted: system reset during flash operation can cause permanent stall requiring POR — this may have been a contributing factor
• We are now using PWR_SMPS_1V8_SUPPLIES_LDO and have added SYS.Debug=Serial_Wire in CubeMX on new boards

[Andrew Neil]

Maybe it's something in your code that's blocking SWD - and the "~20 programming cycles" is just a coincidence with when that was introduced ... ?

Have you tried reverting to an older version of your software - something that you were using before those "~20 programming cycles" ?

Or maybe just a simple blinky?

[mvo]

Thank you for the suggestion. However we already performed a full mass erase via UART bootloader, confirmed blank flash, and SWD still fails. With blank flash there is no user code running at all — the chip sits in the ROM bootloader. The UART bootloader connects and works perfectly on the same hardware. Also if we are in the ROM bootloader the SWD also fails to connect.

[Andrew Neil]

Same problem here: Critical Hardware Failure: STM32H743IIT6 Permanent Damage and Overcurrent Issues - by @Amir2647m ?

[mvo]

Update — SWD Pins Shorted to GND

Following up on this thread with a new finding.

After exhausting all software recovery options (mass erase via UART bootloader, option bytes confirmed clean — RDP=0xAA, no WRP, no PCROP), we measured the resistance between GND and the SWD pins on the damaged board with the board fully powered off and all connections removed.

Finding:

• SWDIO (PA13) to GND: 1–2 Ω
• SWCLK (PA14) to GND: 1–2 Ω
• Normal GPIO pins: no such low resistance

This is essentially a short on both SWD pins. This explains why every recovery attempt failed — the SWD interface was physically shorted, not locked by software.

---

Questions:

We could not find any recommendation in ST's official documentation regarding protection of SWD/JTAG lines on the PCB — specifically:

1. Should series resistors be placed on SWDIO and SWCLK between the debug connector and the MCU? If yes, what value is recommended?
2. Should ESD protection diodes (TVS or similar) be placed on SWD lines? Are there any restrictions on capacitance that would affect SWD signal integrity?
3. Is there an official ST recommendation or application note that covers protection of the debug interface lines against overvoltage or current injection?
4. Is the STM32H7A3 more sensitive to this type of damage than other STM32 families such as STM32G4? 

We want to understand the correct hardware design practice to prevent this from happening on future PCB revisions. Any official documentation or confirmed community experience would be greatly appreciated.

[Ozone]

> This is essentially a short on both SWD pins. This explains why every recovery attempt failed — the SWD interface was physically shorted, not locked by software.

I would highly recommend to review the schematics, and the connection to the debug pod you are using.
Most probably, protective components of the involved SWD/GPIO pins are blown due to overload.