I've got a devices that is really strange, it drops USB periodically. By periodically I mean on a weekly (or biweekly) basis. By dropping out I mean windows loses the handle to the driver. Dropouts a not tolerated well by those using the devices. The weird thing is I use a similar design on most of the products that we have (more on that later), for some reason this one doesn't want to play nicely, some of the other devices run for months to years (with the same design but different layout) with zero issues.

It's only on some of the devices so that probably rules out firmware/software.

The USB is 2.0 FS, running to an STM32, with an ESD diode chip in the middle.

Schematic (D+ and D- and OSC_IN and OSC_OUT (oscillator design was inherited) go to their corresponding pins)

enter image description here

A better question would be, how do I test for these dropouts? Is there some method that could monitor a device for very long periods of time with millions of packets going by and find the source of the error?

  • 1
    It's only on some of the devices so I think it's hardware related. – laptop2d Aug 14 at 2:54
  • 1
    "with an ESD diode chip in the middle" sounds very suspicious. – Ale..chenski Aug 14 at 4:35
  • 1
    Do you capture and log the system exceptions? (eg: hardfaults) – Jeroen3 Aug 14 at 6:14
  • 1
    As a small remark, the caps C13-C14 are too high (should be 22-33pF), and are on wrong side of R5-R6. The entire sequence of components is in reverse. Caps should be on IC/PHY side (to limit slew rate), then Rs, and ESD protection should be first, near USB connector. But these are small things. How long is the cable between host and devices? – Ale..chenski Aug 14 at 20:08
  • 1
    BTW, what is your USB host? PC? Windows? Linux? Also, caps to shield is bad, signals would be susceptible to external EM interference, CFL bulb turning on might disrupt the communication. – Ale..chenski Aug 14 at 21:27
up vote 11 down vote accepted

Is there some method that could monitor a device for very long periods of time with millions of packets going by and find the source of the error?

Yes. The device is called "USB protocol analyzer".

If you monitor only the host software side, the maximum you can see is that there was some "transaction error", and the port can or can't recover after dropping. USB protocol has hardware-assisted means to re-try failing transactions, and software doesn't have any visibility into "error count". So you need to identify the root cause of the error at physical level, on D+/D- wires.

There are affordable USB analyzers, especially for USB 1.1 (FS 12 Mbps) rate. A good analyzer can be set for a sophisticated trigger while monitoring traffic in a long loop, or even recording the entire traffic up to capacity of your hard drive. I would recommend a small Teledyne/Lecroy model Mercury T2, but other guys like Ellisys and Totalphase Beagle are getting better and better.

However you need to be careful, since the analyzers are somewhat invasive, and their connectors/internals do have some effect on signal integrity. In case of flaky connection and rare error rate the analyzer can either improve the signal (and you might never see the problem) or can kill the link functionality (which will helpful to pinpoint the problem).

So in short you need to identify who is at fault when the device drop happens. It could be (a) device makes wrong responses to a valid USB protocol, (b) channel signal integrity problem, or (c) host hardware has a bug in handling some peculiarities of USB protocol.

I would start with (b) and check if all signals on the bus meet basic USB signal specifications: pattern frequency within 2000 ppm, jitter within the norm, signal edges are monotonic, and signal eye meet the diagram mask, all over your specific cables, devices, and hosts. There are standard procedures described in USB-IF website how to perform the electrical tests within USB compliance program.

If the signals meet basic FS signal specifications, the Protocol analyzer would be the next thing to deploy. If might be challenging to set up proper trigger and have correct interpretation of bus events leading to error. If you don't have experience with USB analyzers, you might need to take some training or get a consultant.

I had a similar problem with something I was working on. It seems the signal levels were rather marginal and the whole thing became sensitive to the quality or length of the USB cable. You could start to look at signal levels, and maybe try a shorter cable and see if that improves things. All USB cables are not equal - some have thicker conductors for the data lines than others.

We had similar problems in past. USB serial device would on some PCs fine for months and on some we would lose communication every week. We started with running three devices on two identical windows PCs (combination that would have problems sometimes) and one Ubuntu box with simple log to disk software. After some time, one windows box lost it - port just disappeared. Windows USB driver stack (this was Win7) is bunch of legacy stuff that apparently can't handle quirks of FTDI chips. So my suggestion is run test on two identical configurations + third different one. If it stops responding, you have problem with device + usb controller + driver combination. If not, its probably signal issue - USB monitor could help you.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.