AM3517 HOSTUSB doesn't work

I tried out a USB flash drive on my AM3517 EVM and it appears to work properly without the errors you are showing.

Have you tried the same USB flash drive with the same kernel version on the EVM board with success? If so there may be something wrong with your particular hardware.

AM3517 EVM Terminal said:

root@omap3517-evm:~# usb 1-1: new high speed USB device using ehci-omap and address 2
usb 1-1: New USB device found, idVendor=0951, idProduct=1607
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: DataTraveler 2.0
usb 1-1: Manufacturer: Kingston
usb 1-1: SerialNumber: 0014780EC5F7F91035970099
usb 1-1: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
scsi 0:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 3911616 512-byte logical blocks: (2.00 GB/1.86 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI removable disk

root@omap3517-evm:~# mkdir /mnt/usb_flash
root@omap3517-evm:~# mount /dev/sda1 /mnt/usb_flash/
root@omap3517-evm:~# cd /mnt/usb_flash/

usb 1-1 is High-Speed USB OTG Controller.

usb 2-1: is Multiport USB1, ULPI interface, connect with USB3320 transceiver.

usb 1-1 is OK on my board, but usb 2-1 is wrong.

The SMSC USB3220 requires a clean power supply.  You may need to isolate the USB3220 power supply from other power supplies on the board with a good low pass filter.  TI has seem similar issues on previous EVMs and they were eliminated by isolating the USB3220 power supply.

Sorry to post on such an old thread but we seem to be having a very similar problem with the USB3220 device attached to an AM3517. In our application this port connects to an external hub which has two USB CDC type devices attached downstream. Everything works great for a while but given enough time >24hours eventually we get the following:

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling...

usb 2-1.2: ti_interrupt_callback - nonzero urb status, -32

usb 2-1: USB disconnect, address 2

usb 2-1.2: ti_interrupt_callback - nonzero urb status, -32

usb 2-1.2: ti_interrupt_callback - resubmit interrupt urb failed, -19

usb 2-1.2: ti_bulk_in_callback - nonzero urb status, -71

usb 2-1.2: ti_bulk_in_callback - stopping read!

usb 2-1: clear tt 5 (9053) error -19

usb 2-1: clear tt 5 (1053) error -19

usb 2-1.1: USB disconnect, address 3

usb 2-1.2: USB disconnect, address 4

usb 2-1.5: USB disconnect, address 5

From that point on the port stops functioning until the whole system is reboot.

Do you have any more details on the type of lowpass filter you have found to help this situation (i.e. topology and cutoff frequency)? Below is the current circuit we are using for the USB3220:

You should contact SMSC and ask them to make a low pass filter recommendation.  One good way is to isolate the supply is by using a dedicated LDO voltage regulator, but this may not meet your product cost goals.

You should also consider using the TI TUSB1210.  It is available in the same size package with a similar pin assignment which allows your PCB design to support both devices with a few component stuffing options.

Regards,

Paul

Paul and others,

I'm responding for Andrew as he is out.  We've created a new version of the board that supports using the TUSB1210 part and we are still seeing the problem.  Included below is the schematic (we initially tried the new board with the SMSC USB 3320 but still had the problem) - I've modified it by hand to show the change in the population of the following components: R137-DNA, R194-0, U17-pin12 add C173, U17-TUSB1210.

We are still seeing the same error trace as above (or similar):

hub 2-0:1.0: port 1 disabled by hub (EMI?), re-enabling...

usb 2-1.2: ti_interrupt_callback - nonzero urb status, -32

usb 2-1: USB disconnect, address 2

usb 2-1.2: ti_interrupt_callback - nonzero urb status, -32

usb 2-1.2: ti_interrupt_callback - resubmit interrupt urb failed, -19

usb 2-1.2: ti_bulk_in_callback - nonzero urb status, -71

usb 2-1.2: ti_bulk_in_callback - stopping read!

usb 2-1: clear tt 5 (9053) error -19

usb 2-1: clear tt 5 (1053) error -19

usb 2-1.1: USB disconnect, address 3

usb 2-1.2: USB disconnect, address 4

usb 2-1.5: USB disconnect, address 5

Does anyone have any electrical or software advise for how to eliminate this problem or recover gracefully from the problem?  The host uses the USB connection to talk to other (fixed) devices in the system, so no user interaction to "unplug, then re-plug" is possible.

It may ne necessary to dig deeper into what is happing on the bus when the problem occurs.

Is it possible to monitor the USB data with a protocol analyzer and trigger on any error?  If so, this may provide some additional information to help understand the problem.

Regards,

Paul

Paul,

Thanks for your response.

We have a Lecroy CATC Advisor for viewing traces and might be able to hook that up and monitor as you suggest.  We've done this on some systems already and have not seen significant errors noted by the analyzer.

Are there any specific USB tools or test equipment that you have used for testing USB host designs that you would recommend?

One thing that wasn't mentioned in my earlier e-mails is that we are using a non-standard USB cable assembly for the connection from the display board host to the controller board.  This is due to the need to route the hub cable through some physical obstructions (sorry, trying to be vague on purpose). 

The cable starts as a standard USB 2.0 compliant cable with a regular A connector and mini-B connector.  The regular A connector is cut off and routed through the hardware.  The cut-off end is then formed into 4 wires + shield and connected to a 5-pin crimp-pin connector with .1 in spacing (female).  That connector is then mated to the corresponding 5-pin male header on the control board.

Let me know if you know of any good tools,

Any luck solving this problem?  I am in the same boat.

Thank you,

--Brian

Brian,

Short answer is no.

What we found is that the USB connection is not robust in an electrically noisy environment. 

To mitigate the problem on the electrical side, we worked hard to ensure that any electrical noise that could was injected into the ground, power, or shield of the cabling (EMI or directly induced via noise coupled in through the power supply or other electrical sources) was minimized.  We were able to verify via scope traces that certain conditions (e.g. relays changing state that caused motors or other devices to turn on) could actually corrupt the USB signal and were probably the cause of the EMI? error messages.  We also changed USB ports from the EHCI port that could only work in HS mode (with lower differential voltages) to the MUSB port and forced the MUSB port to FS (disabling HS in the MUSB driver) to use the higher differential signalling when in FS mode.  Other things that might be tried would be use an electrically isolated USB connection (we did not have time to try this due to scheduling pressure).

To mitigate the problem on the software side, we compiled the MUSB driver as a module and put checks into our application to detect when communication to devices over the USB connection was interrupted.  If communication was interrupted, we put in a mechanism to unload and reload the USB driver (we were unable to figure out how to get the USB driver to reset properly so took the brute force approach...).  If the reload did not work, we reset the entire system by rebooting Linux and restarting our application.

So, the best we were able to do was to reduce the occurrence as much as possible and put in software mitigation to get us out of the condition if it did occur.

Hope this helps,

Bill

Thank you for the reply Bill,

My design has one slight difference from yours in that the USB is staying on board and communicating to another chip.  At first I was concentrating on the chip it connects to (Ethernet PHY).  I then was concentrating on the ULPI interface.  There is a significant amount of over and undershoot in the buss (~500mV).  On my next layout I am adding inline resistors to see if I can clean that up a bit.  I am also planning on attempting to clean up the power some more.  Although I think that is pretty good. Like you I have ferrites and lots of bulk capacitance.  After all this I am arriving at the same conclusion I think you have.  The USB differential pair is the weak link.  I will try to push this around some to give it even more space away from other components and traces.  I like your suggestion to operate in FS mode.  I will give this a try. 

Thank you again for your help,

--Brian

Hello all,

I wanted to give you all an update on this issue and let you know we have been able to identify and fix the problem. 

The issue ended up being with jitter on the 60MHz clock on the ULPI interface generated by the DM3730 processor.

Advisory 2.1 in the latest errata starts to explain the issue with PLL registers and drift.  We were having further trouble as the values we thought we were setting were getting over written by an automated routine. After changing the master clock to 38.4MHz from 26MHz and setting up the DPLL5 registers recommended in the errata we are solid at all temperatures.

http://www.ti.com/lit/er/sprz319e/sprz319e.pdf

Thank you all for all your help in troubleshooting this issue,

--Brian

Brian,

I'm glad you were able to resolve your USB problem.  However, I would like to clarify something in this thread to prevent possible confusion.

The original post began discussing the USB host subsystem in the AM3517, but it sounds like your product is using the DM3730.

The USB host subsystems in both devices are similar, but these devices have different internal components with different operating requirements.

The DM3730 supports a 38.4 MHz clock source, but the AM3517 only supports a 26 MHz clock source.

Also the Errata you mentioned does not apply to the AM3517 since uses a different DPLL which has lower long term frequency drift.

I want to make sure anyone that begins reading the thread with a focus on AM3517 doesn’t skip down to your DM3730 comments and make the mistake of assuming they apply to AM3517.  For example, your comments about Advisory 2.1 and the 38.4 MHz clock source does not apply to AM3517.

Regards,
Paul

Excellent Point Paul,

I was excited to publish our findings to the community but forgot about the origins of the thread.  There might be a better place for this response. :)

Thank you,

--Brian