STM32H750 and USB3300-EZK has stopped working

[sophie]

I designed a board that uses a STM32H750 with a USB3300-EZK that has stopped communicating over USB. It's been having intermittent issues for the last day or so (sometimes I'd need to power cycle the board before it would show up, but then it would work flawlessly). Earlier today, I plugged it into a Raspberry Pi, and then it died fully. I've plugged it into that Pi before without issue.

Despite probably hundreds of cycles at this point, I haven't gotten the USB to work again. The PHY is generating a stable 60MHz clock, and DIR is low. I haven't observed any communication on the D0..8 lines. That leads me to believe the problem is with the STM32.

I am using pc2_c and pc3_c, which are supposed to work with USB, although I've heard they're more susceptible to (static?) damage.

I do have a second board that I can switch to, although I don't have a third prototype, and it really would be good to figure out what happened here so I can prevent it from happening again.

[AScha.3]

Hi,

Probably you killed a xx_c pin.

It happened to me when using such an pin for SPI to a small display. It was working until I tested it with higher clock rate. Was working some seconds then died away.

This pin never worked again.

So I avoid these xx_c pins for any output signal, just using it as a slow input is okay, or as analog input.

The _c pins are connected through an anlog switch - that can easily be destroyed ....

So maybe you killed it by driving more than 1mA on these pins...

https://community.st.com/t5/stm32-mcus-products/stm32h723-ulpi-and-pc2-c-pc3-c/m-p/867985#M290807

Check: set pin as gpio output (remove connected hardware, that drives this pin) and toggle it, just for test: check with scope, pin working or not.

[FBL]

Hi @sophie 

Can you confirm whether you are operating close to ULPI timing limits? Which STM32H750 revision Rev V or Rev Y are you using?

Enabling IO compensation cell and setting VERY_HIGH speed increases timing margin against jitter. Also, can you check your data channel load? Too much load slows edges and increases skew and jitter, and can break setup/hold timing margins. Check this FAQ How to check compatibility on USB ULPI transceiver

[sophie]

I'm a little worried I destroyed the _c pins. Although for ULPI they're input pins, right? So there shouldn't really be a risk of overdrive. I don't really have a way to remove the PHY from the circuit without fully taking it off the board, which I would prefer not to do if possible.

[sophie]

Looks like it's a REV V. I'm not operating close to ULPI limits.

To be clear, things were working totally fine until suddenly USB stopped working. Previous glitches I had were able to be resolved with a replug, but now it's totally dead and I can't get the USB to show up despite hundreds of replugs. I flashed identical firmware onto a second board and it works fine. This leads me to believe there's something that physically changed that is causing issues, and not a signal/timing issue.

[AScha.3]

>Although for ULPI they're input pins, right? 

Right, so it should not damage them. (As i did by increasing clock from 12M to 32 Mhz , about)

+

>working totally fine until suddenly USB stopped working.

This happened while it was running/working ? So not at re-connecting/plugging in ? (Then also no ESD could be the reason.)

+

> I haven't observed any communication on the D0..8 lines.

This is a device - right ? Then first signal is pulling D+hi ; did you look with a scope, what happens on the data D+/- lines on connecting ?

[sophie]

This happened when plugging in. I plugged it into the Pi and it didn't show up and I wasn't able to get the USB to work from that point onward. Before that it was plugged into my laptop and working without issue.

> This is a device - right ? Then first signal is pulling D+hi ; did you look with a scope, what happens on the data D+/- lines on connecting ?

Surely there needs to be activity on the ULPI bus first to get the PHY into a state where it can communicate over USB? I can try probing D+/D- when I get home but I'm skeptical there will be anything since the PHY and MCU aren't communicating. It's a device yes.

[AScha.3]

>This happened when plugging in.

So ESD could be the reason.

Then the USB3300 could be damaged .

+

What is the supply , when you connect to Pi ? is it with ground or floating ? (the Pi , STM is connected to PC , with mains grond - or not ? )

[TDK]

If you have the means, replace the USB3300 chip and see if it works. Takes about 10 minutes with a hot air gun and may solve the mystery.

> It's been having intermittent issues for the last day or so

Sounds like this was not a one-time event but rather something built up over time, which is not unheard of for ESD but could also be a manufacturing issue--a cold solder joint slowly failing over time.

If you want to verify Px_C pins still work, you could set them as output and toggle, verify the input follows output. You could also set them as analog and verify ADC returns appropriate values but this may take more rework than is possible.

Another metric would be looking at current draw which should remain consistent throughout the life of the device. If it's 5 mA higher on the failed device, yep, probably something damaged.

As for why, well, is there any ESD protection at all on pins exposed externally? Is the device itself protected from damage or shorting by a metallic object?

There could also be design issues on the design that cause it to slowly fail over time.

[sophie]

The Pi is not grounded, I don't think, although my board also connects to VGA, and that itself may be grounded. I'm not actually sure. Although the board was plugged into VGA and was working fine before I plugged it into the Pi (which didn't involve any changes on the VGA side)