SWD connection failed multiple times on STM32H725

[niallp]

We have a batch of custom boards using the STM32H725IGK3 and have experienced several failures getting started with them as the SWD interface appears to be fried. Initially we thought just bad luck with the first couple (inexperienced engineers or ?) but the most recent unit failed after a few successful programming and debugging sessions. 

Do these processors need special handling or design considerations ? Our debug header follows previous designs, with Vcc, GND, nRST, SWDIO, SWCLK provided. nRST is gated with a couple other inputs to the MCU while SWDIO and SWCLK just have 100R series resistors to protect possible voltage conflict. So far just default 3v3 supply.

When the boards were working, SWDIO showed Vcc while SWCLK showed 0V before any connections (expected based on internal pullups) while now the pins show about 0.8V until the STLINK/V2 is connected (upon which its pullup/downs take over). 

The STLINK pod has been tested and working on a NUCLEO_H723.

It looks like we'll need the MCUs replaced (BGAs, ughh :( but we're not going to get far if they only last a day ...

[TDK]

> custom boards using the STM32H725IGK3 and have experienced several failures

Perhaps an issue in the schematic design. Post it if you can. Look at VDD voltages. Ensure VCAP pins are 1.2 V and has decoupling caps. Connect all VSS pins.

The processors are quite robust.

Nucleo boards have a good hardware design. If you have the same design as those, they won't fail after a day.

[niallp]

Might be on to something, Vcap is 0 V. Other research indicated we might have an issue with LDO vs. SMPS. though my reading so far indicates the LDO should be re-enabled after every POR even if rogue code did switch it off.

The board is configured in LDO only mode, all Vss connected, VDDLDO connected to VDD and externally regulated 3v3 supply. We are using external power supervisor so we have PDR_ON disabled.

Currently trying to see if I can access via DFU mode through UART but not working yet. If LDO is out of action maybe I can supply Vcore externally ? 

[AScha.3]

> so we have PDR_ON disabled.

Connect PDR_ON to VDD . Then try again...i made this mistake also one time.

[TDK]

If you're checking all this on a board that died, I don't expect it to come back to life.

Check resistance from VCAP to GND.

I don't see any issue in what you've described, but without the schematic we're probably not being presented with the problem. If VCAP=0, no need to check DFU or bootloader or anything. It's not in a viable state.

[niallp]

> If you're checking all this on a board that died, I don't expect it to come back to life.

True, forever hopeful ... it can get deader though ...

> Check resistance from VCAP to GND.

Initially looked to be 6k to 16k (depending on polarity so some diode biasing happening). After powering board again to recheck the Vcap voltage (260 mV) it was stable for a few minutes then started pulling too much current. Disconnect and recheck, Vcap and Vcc now shorted to ground.

Definitely not coming back from this ! 

Still a mystery why it (and 2 other boards) have failed, investigation continues ...

Power supply connections shown below, if anyone sees something *** please lemme know.

[AScha.3]

I dont know , what you did - but i seen some dead cpu at work, and all had some contact with high voltage,

by connecting mains to serial input (no choke!) or some ESD event, maybe even from debug connection.

So can you guarantee , that no ESD or a supply without mains/ground is connected ?

Because i never seen some cpu's dying just because of bad mood .

And your basic VDD+GND connections seem ok.

[jameswilliam]

This sounds like a hardware-level issue rather than bad luck — the ~0.8 V on SWDIO/SWCLK usually means partial IO damage or latch-up. The nRST gating is also risky. Try giving the reset line a direct connection, add 330–1 kΩ series resistors on SWD lines, and weak pull-ups (10 kΩ) to 3.3 V.

Also check your power sequencing — if peripherals drive SWD pins before VDDIO is up, it can fry the interface. Adding ESD diodes and making sure SWD isn’t shared with active nets can prevent future failures.

Hope this helps bro.

[niallp]

@AScha.3  I guess ESD is always a possibility even with precautions. With 3 boards down in different locations it feels like some some design issue, possibly need external ESD protection on the SWD pins (the Nucleo board does include them, as well as a level convertor)

@jameswilliam  we definitely had some flapping grounds on the first couple boards to fail so not that unexpected, power supply sequencing also a bit random. Sounds like we have an excessively fragile design at the moment and will need to fix on next revision.

Unfortunately rather long lead times due to special PCB materials, we'll have to be extra careful on our remaining prototypes !

Thanks for all the input.

[niallp · Accepted solution]

A followup in case anyone else lands here ... the initial problem turned out to be incorrectly configured power supply, the default for the H725 assumes the SMPS supply is used, while we were using the LDO (same as the Nucleo).

The .ioc needs updating in CubeMX under System Core > RCC > Parameter Settings > SupplySource = PWR_LDO_SUPPLY

Bricked boards can be recovered by holding in reset during powerup then releasing reset as programmer connects.

https://community.st.com/t5/stm32-mcus/unable-to-connect-to-stm32h7-devices/ta-p/49296