US

Please read the subject as USB related queries.

The SMSC USB3320 PHY and OMAP35xx devices have an interoperability issue described in the Silicon Errata (TI document # SPRZ278) Advisory 3.1.1.193.  The current version of the errata states there is no workaround, but TI has a new ULPI USB PHY (TUSB1210) that does not have this interoperability issue.  You will need to contact your local TI sales representative or distributor to get pricing and availability information for the TI TUSB1210.

has anyone verified the TUSB1210 works with the OMAP3530?

Also, will future revs of the OMAP3530 fix this issue?

Are there any software workarounds like completely re-initializing the EHCI port?

Thanks,
Cliff

Yes, we have replaced the SMSC USB3320 on the OMAP3EVM with a TI TUSB1210 and it works as expected.

Currently there are no plans to update the OMAP3530.

You should be able to reinitialize the EHCI controller and the external ULPI PHY which will cause the attached USB device to disconnect, connect, and enumerate.  This may be an acceptable software workaround if your application allows this re-enumeration sequence.

Regards,

Paul   

Can you point me to the schematics for this EVM design?  I checked the EVM schematics on the mistral site, and they still show the USB3320.

Thanks,
Cliff 

The EVM design was not updated to use a TUSB1210.  A limited number of EVMs were modified to use the TUSB1210 and these EVMs were used to verify operation with OMAP3530.

I have attached a Power Point file that shows the changes required to add a TUSB1210 to an EVM.

Regards,

Paul

We are testing our design with the TUSB1210, and running into a few problems.  The design has two phys.  The first is an internal USB port that connects to a on-board GSM module.  This port seems to be working fine.  The 2nd Phy connects to an external port and is giving us problems.  We see periodic resets on the port.  

root@beagleboard:~# usb 1-1: reset high speed USB device number 2 using ehci-omap

In this case, device 2 is a flash drive:

root@beagleboard:~# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 3538:0054 Power Quotient International Co., Ltd Flash Drive (2GB)
Bus 001 Device 003: ID 0af0:8800 Option 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 2001:f103 D-Link Corp. [hex] 
Bus 002 Device 003: ID 2001:3c05 D-Link Corp. [hex] DUB-E100 Fast Ethernet [asix]

Running a file system stress test (http://svn.bec-systems.com/pub/fs_stress_test/), we see perhaps a dozen errors when writing 500MB to the card.  This varies, gets worse/better at times.

Below is the schematic.  Appreciate any thoughts on debugging this and things we should be looking for.

Thanks,
Cliff 

6471.Selection_095.pdf

The ferrite bead inserted on the ground connection to the USB connector may be causing signal integrity issues.  It is not common to insert a ferrite bead on this ground pin.  If you are using the AM37xx processor, confirm DPLL5 is configured as described in Advisory 1.111 of the silicon errata.

Regards,

Paul

peaves said:

The ferrite bead inserted on the ground connection to the USB connector may be causing signal integrity issues.  It is not common to insert a ferrite bead on this ground pin.  If you are using the AM37xx processor, confirm DPLL5 is configured as described in Advisory 1.111 of the silicon errata.

 

Regards,

Paul

 

Thanks for the ideas, we are using a OMAP3530

we removed the bead on the ground pin with no change.  We'll keep digging ...

Have you performed the standard compliance tests recommended by USBIF?

The eye diagram test may provide some insight on transmit data signal quality.

Are you connecting a certified USB device for your testing?

Regards,

Paul

peaves said:

Have you performed the standard compliance tests recommended by USBIF?

 

The eye diagram test may provide some insight on transmit data signal quality.

 

Are you connecting a certified USB device for your testing?

 

Regards,

Paul

 

No, we have not done this level of testing yet, and it would take us some time to get access to this level of test equipment.  In the last rev of the design, we used a SMSC USB3320 phy, and our filesystem stress test worked.  Most of the design is the same, just the phy was replaced.  We're currently re-verifying power.  It seems odd that we get the periodic resets -- its almost as if there is some glitch that periodically happens in the system.

We tested the file system stress test with a number of consumer grade flash drives.  They all work fine on the OTG port, and with the last Rev of this board with the SMSC phys -- perhaps we are on the edge with something ...

Thanks
Cliff 

A few more bits of information:

We see two types of failures:

1) USB resets

2) silent data errors

Running dd tests, we only observe resets on writes, but not on reads (see log below).

Based on this thread, http://groups.google.com/group/beagleboard/browse_frm/thread/5b8385f0bb1f63da/b1997852c1de4fd4, we've tried a number of experiments with power supplies, but don't have any conclusive results yet.

Cliff

root@beagleboard:~# 

root@beagleboard:~# 

root@beagleboard:~# 

root@beagleboard:~# dd if=/dev/sda of=/dev/null bs=1M

979+1 records in

979+1 records out

root@beagleboard:~# dd if=/dev/sda of=/dev/null bs=1M

979+1 records in

979+1 records out

root@beagleboard:~# dd if=/dev/sda of=/dev/null bs=1M

979+1 records in

979+1 records out

root@beagleboard:~# dd if=/dev/random of=/dev/sda bs=1M 

<6>usb 1-1: reset high speed USB device number 2 using ehci-omap

usb 1-1: reset high speed USB device number 2 using ehci-omap

<6>usb 1-1: reset high speed USB device number 2 using ehci-omap

usb 1-1: reset high speed USB device number 2 using ehci-omap

<6>usb 1-1: reset high speed USB device number 2 using ehci-omap

usb 1-1: reset high speed USB device number 2 using ehci-omap

<6>usb 1-1: reset high speed USB device number 2 using ehci-omap

usb 1-1: reset high speed USB device number 2 using ehci-omap

<6>usb 1-1: reset high speed USB device number 2 using ehci-omap

usb 1-1: reset high speed USB device number 2 using ehci-omap

We're still trying to get the OMAP3530 + TUBS1210 working ...

We have an external port connected to OMAP3530 EHCI port 1.

We have an internal port connected to OMAP3530 EHCI port 2.

Both are using the TUSB1210 phys.

As an experiment, we jumpered EHCI port 2 to the external port so that we could test -- the results are far better.  Updated, we don't see any data errors when we patch OMAP3530 EHCI port 2 to the external port.  Its surprising it works better even with the nasty modification.  So it appears port 2 works on this design and port 1 does not.

Both TUSB1210 phys are in the same location of the board, and both have nearly equivalent layouts, so its a real mystery why one works significantly better than the other.  

Thanks,
Clifff

Updated, we don't see any data errors with OMAP3530 Port 2 + TUSB1210, but we do see errors with OMAP3530 Port1 + TUSB1210.

With the above modification, the modification is directly underneath both phys (the array of 9-vias are thermal vias for both phys).  So the external connector diff pairs, ESD protection are the same for both test setups.  The only real difference is the OMAP3530 EHCI port. 

Has anyone verified the TUSB1210 connected to the OMAP3530 EHCI port 1, or is there reason to believe this may not work?

Thanks,
Cliff 

Here is another thread that may be useful: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/29680/517661.aspx

We are definitely hitting the condition detected in this patch (http://marc.info/?l=linux-usb&m=129472850014890&w=2), but not sure of the cause yet.

Certification USB2.0 was done with OMAP3530 and TUSB1210. No similar problem was observed.

In order to be able to better understand your issue we would need some data to investigate.

In your particular test case would it be possible to have DP/DM activity log (with CATC tool or other) and also a trace of 12-pin ULPI interface pins (CLK, STP, NXT, DIR, DATA) ?

Thks Rgds