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.

 

 

[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.

[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 ?

[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]

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.

[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]

I unfortunately don't have a spare USB3300 (or a spare STM32H7) but I may have to pick one up.

The reason why I think it's a problem with the STM32H7, and not the USB3300, is because DIR and NXT are both low, which should imply that the mcu is good to put data on the data bus, but that never happens. I did write a little program to check the value of pc2 and pc3 and they both came back low though, even when I enable the internal pull-up resistor. So it seems like the analog switch might be okay.

I don't have any ESD protection but supposedly the USB3300 has it built-in. The only other I/O is a VGA output which is connected to the STM32H7 through a resistor DAC. Unfortunately it has no ESD protection, although the dead board seems uncorrelated with plugging/unplugging from the VGA.