Short circuit on STM32H750

[Peaga]

Hello!

It's been a while since I'm working with STM32H7 MCUs and now, some of the products using it are returning from my customers, not working at all. Analyzing the board, I get a short circuit between 3V3 and GND and after removing the MCU, the short circuit is gone. Nothing more on board is damaged, so putting a new MCU solves the issue and than the product is returned to the customer.

I can't share the board schematic due confidential rules on my company but basically it's a 12VDC device with 3V3 and 5V regulators, 4 layers PCB. All MCU pins are in use and there are the following features:

- 1 QuadSPI (Serial flash memory)

- 1 SPI (EEPROM)

- 1 I2C (16x2 LCD)

- 1 CAN (ATA transceiver)

- 1 USB Host

- 6 UARTs (4 RS485 and 2 RS232 by transistor)

- 1 PWM output (Buzzer)

- GPIOs (8 relays, 5 push-buttons and general I/Os)

All genereal inputs have diode protection and the outputs are transistor based. The push-buttons active on GND, counting only with the internal pull-ups. CAN and RS485 have ESD protections and all pins were checked by 5V tolarance. The software is burned to internal and external flash using ST-LINK/V2.

So I'm kind of lost of what's causing this issue. The first thought was about ESD, as most of the customers told me that they just plugged the 12VDC power supply with nothing else connected to the board. But I don't think SMT32 is that sensitive...

Do you guys have any idea?

Thanks a lot!

[TDK]

Could be a voltage overshoot on startup or inrush otherwise affecting things. Pins aren't 5V tolerant until VDD is applied.

[Peaga]

Hello @TDK​ , thanks for your point!

CAN (ATA6562), EEPROM (M95M01) and RS485 (MAX485CSA) are working at 5V level but I think at idle state their output level are lower than 5V... Only RS232 (by transistor) uses the high level for RX, at transistor's collector (1k resistor). I'm not sure if this can cause the issue...

[Max]

You may want to return the failing devices to ST: after analysis ST QA should be able to tell you more about what happened to the STM32, for example which pin caused the fail and if an ESD is responsible for the fail.

[HMull.1]

To test your theory about plug in events, have you tried the action maybe 100 or 200 times after replacing the MCU? Isolate pins that could in theory be suspect and probe during powerup. These kinds of tests might take time to execute, but should be valuable.

I would also not discard the idea of a production/assembly issue on your PCB that you are inadvertently "fixing"by applying heat to the board.

If you have a failed device, carefully check all the pins for hairline shorts or the likes. A heat flow issue or GND issue on the board can cause repeatable production assembly mistakes.

[TDK]

That's what I would look at first. Get a scope on all power rails and signals lines coming into the STM32 and verify levels during startup.

[Tesla DeLorean]

I'd generally expect this to be due to excessive potentials on the board, rather than ESD at a pin level.

How many layers does the PCB have? Good/Solid ground bonding? Ground connects first type plugs/interfaces? Conduction paths where the IC is the easiest route?

Automotive? Huge Load-Dump events?

[Peaga]

Hello, thanks for all feedback!

@TDK​, ok, I'll very all levels during startup. I will also check the code, as there's a note on datasheet about input pins with weak pull-up enabled and higher voltages.

@Community member​, that's was my first idea. I'm trying to collect a good number of chips but I really don't know how to proceed next. Should I contact my local ST team?

@Community member​, it's also a good point. After production and assembly process, all boards are tested by operators but not right after the assembly, it takes some time. At development process I've lost one STM32H743 by plugging/unplugging the ST Link on an already powered board, so I don't know if it's just a coincidence but my team is very careful on testing process.

@Community member​, it's a 4 layers PCB, solid ground and good routes. It's not an automotive device but an access control one, basically a controller for RFID readers. It used to have a "twin brother" in the past, but using a PIC32 as MCU. The main power supply is from a J4 connector and there's only GND as output.

[S.Ma]

Could there be an in rush current when configuring the IOs? For fun when out of luck, add a 500 msec sw delay at the start of the code to see if it does something. Sometime to limit rush current a serial resistor on output gpio might help better than protection diod.

[HMull.1]

The fact that you lost an already powered board by plugging in an ST Link points to something else, I think. Plugging in an ST Link alone should not affect the MCU and certainly not cause a catastrophic failure.

I guess it also depends on your ST Link plug/connection but this sounds more and more like an issue that occurs due to handling of the powered board or touching of components.

Given all of the above, I think the best solution is still to carefully probe the board at various sensitive locations while handling and hot plugging. No need to theorize, just test and believe what you see