Hi friends,
We're using a board based on the beagle-xm reference design. It exposes 3 USB ports from the LAN9514 via the USB3320 and upstream the DM3730. So DM3730's HSUSB2_* connected to USB2HS_DAT0..7 on USB3320 and its DM/DP connected to SMSC LAN9514's upstream USBDP0/DM0. The 9514's PRTCTLx then controls TPS2062's enables for the physical port VBUS.
This all works great on most boards and worked reliably. However, now in volume production, we found that we are getting about 10%-20% failed boards in burn-in testing of USB ports. The mode of failure we're seeing is that the system starts exhibiting failures where the USB ports all disappear at some point in testing (eg: 13 hours after testing started, sometimes longer 87 hours in one case):
usb 1-2: USB disconnect, address 2
usb 1-2.1: USB disconnect, address 3
smsc95xx 1-2.1:1.0: usb0: unregister 'smsc95xx' usb-ehci-omap.0-2.1,
smsc95xx USB 2.0 Ethernet
usb 1-2.2: USB disconnect, address 6
usb 1-2.3: USB disconnect, address 4
usb 1-2.5: USB disconnect, address 5
Once this failure has occurred, the USB ports (all from 9514) stop working completely. Power cycling does not resolve it, nor does reflashing of firmware. So it would appear at first glance that either the SMSC LAN9514 or the USB3320 became faulty. I'm trying to assist the hardware team isolate which component is becoming faulty.
Are there key signals or pins on the DM3730, USB3320 or SMSC LAN9514 that we should check?
Also, are there debug registers or sysfs debug variables exposed either by the smsc95xx driver or /proc / sys options that we can use to assist in debugging?
Thanks,
jayakumar
