cancel
Showing results for 
Search instead for 
Did you mean: 

Slow Release of Internal 1.5k Pullup on USB D+?

jvavra
Associate III

I have a number of full-speed USB-powered devices I'm working with. All use STMicro microcontrollers (a few different models, including STM32F205, L432, etc.). All of the different devices use the same USB circuitry (including the 1.5k internal pullup on the D+ line), but for some reason on the latest build (700 pieces) of a particular device we're seeing intermittent USB enumeration failures. If I continually cycle USB power, I can get SOME devices to fail anywhere from 10-75% of the time, while some seemingly never fail. Using a USB protocol analyzer, I captured data both when one device did not enumerate and when it does. 

Here's an instance of not enumerating:

0693W00000JNItuQAH.pngAnd here's a successful enumeration with the exact same device, same cable, PC, etc.:

0693W00000JNIuTQAX.png 

As you can see, there (sometimes) seems to be an issue with the appropriate voltage during the K/J chirp sequence. However, I’m confused why on index #2 of the “bad enumeration�? capture the speed seems to be set to high speed without any J/K chirps having taken place yet. Further, in reading the USB Background article posted by the protocol analyzer manufacturer, it seems the Tiny K/Js I am seeing should be considered spurious and may foul communications. The say the cause is generally the pullup on the D+ line being released too slowly, which creates a voltage divider with the host termination resistors and causes a voltage mismatch. But I seem to see these both during successful and failed enumerations, so I am not sure if they are just a red herring. Lastly, if the micro being slow to disconnect its internal pullup is causing these spurious chirps, do you have any suggestions for how to improve robustness to avoid this?

Here's the USB circuit:

0693W00000JNIvMQAX.png

7 REPLIES 7

> for some reason on the latest build (700 pieces) of a particular device

Which STM32?

Is this construction bus-powered or self-powered? How do you control the DP pullup, from a VBUS detector, or is it up all the time?

JW

Javier1
Principal

>I can get SOME devices to fail anywhere from 10-75% of the time

Sounds like a hardware probelm to me, How are you clocking your boards?

we dont need to firmware by ourselves, lets talk

This particular device uses the STM32F205. All are bus-powered. AFAIK, there is no option to manually control the pullup. It can only be enabled via the VBUS detector.

External 8MHz crystal oscilator.

Are you able to phisically access the mcu's?

Maybe swap (hotgun and flux) one working MCU for one malfunctioning MCU and see what happens?

we dont need to firmware by ourselves, lets talk

> This particular device uses the STM32F205. All are bus-powered.

Does the total capacitance between VBUS and GND conform to the standard, i.e. min.1uF max. 10uF (USB2.0 7.2.4.1 and Upstream Facing Port Bypass Capacitance in Table 7-7)?

If not, you may create slow oscillations on VBUS thus your VDD upon attach. Observe using oscilloscope. You can try to fix this in software by delaying the pullup switchon (probably you can achieve that by delaying startup of the USB stack).

> AFAIK, there is no option to manually control the pullup.

Of course there is - in 'F205, it's controlled by GCCFG.PWRDWN.

> It can only be enabled via the VBUS detector.

There's no point in detecting VBUS in bus-powered devices...

JW

How slow would these oscillations be? I'm not seeing anything on the scope while probing L1 during attach. Voltage is zero, then voltage is 5V.

EDIT: Delaying the USB stack init had no effect.