TUSB7340: USB2.0 device works but USB3.0 device does not work

And when we plug in the USB3.0 flash drive, it just does not detect it at all. It does not downgrade to USB 2.0 device. However, it works if we plug in a USB2.0 flash drive.

What operating system are you running?  Can you get any information on what state the port is in?  If it doesn't drop to USB 2.0, it may have gone to compliance mode.  Have you tried removing it and reinserting it?  Do you see this with multiple USB 3.0 flash drives?  Can you confirm that the port is providing enough current on VBUS?  1A is recommended.

Regards,

JMMN

Any update?

Later on we found out it works fine if we use an external USB3.0 connector but it does not work with the on board connection between TUSB7340 and a Cypress chip CYUSBZ3014. Is there possible the chips are too close and amplitude too big?

Are there AC caps on both TX and RX lines?  How long is the PCB trace?

Regards,

JMMN

Sorry somehow I missed previous notice of your reply.

AC caps only on TX. The PCB trace is short <3 inches.

Hi Junhua,

There should be caps on each set of diff lines, near the transmitter of each pair.

TUSB7340 TX -  (caps) ----------- RX CYUSBZ3014

TUSB7340 RX  ----------- (caps) - TX CYUSBZ3014

Regards,

JMMN

Hi JMMN,

Yes, we did exactly as you suggested.

Sorry my words are a little confusing. "AC caps only on TX" means we have AC caps on both TUSB7340 TX and CYUSBZ3014 TX.

Thanks

Ok, it sounds like the link is going to compliance mode rather than a signal quality issue.  Can you confirm that when you directly connect the host and the device and it doesn't appear, if you do a hard reset of the device, it will then connect at USB 3.0 speeds?  If so, this indicates you may need to adjust the power on reset timing of the host and device to avoid compliance mode entry.

Regards,

JMMN

More description of what we are seeing now.

Out of four ports of  TUSB7340, we have three ports connected to three CYUSBZ3014 on the same board, and have one port connected to an USB connector.

If we do a hard reset of device (CYUSBZ3014/TUSB7340), it does not help. Even if power cycle the whole thing and it only works for one or two out of ten times if not less.

Later on, we changed the two AC caps of the three onboard ports to 50ohm resistor, then most of the time works fine now. But still there are some times does not work, e.g., one out of ten times does not work.

However, for the port connected to a USB connector, it always work well (We tested it many times with an external USB3.0/2.0 device).

Without replacing the AC caps with 50ohm resistors, the TUSB7340 TX waveform is yellow and RX waveform is green. Correct me if I am wrong, I feel like it passes initial LFPS handshake and fails in link training.

It looks the the host and the device are getting out of sync during power on and one side is going to compliance mode.  The green signals look like Polling.LFPS (can you confirm the time base in the scope shot?), but the TUSB7340 has not started polling yet.  Since adding 50 ohm resistors impacts the behavior it is likely an issue with the receiver termination detect where the device is detecting the disabled terminations of the TUSB7340 as enabled.

Can you provide a scope plot from 1-2 minutes after a device fails to enumerate?

The time base is 10ms/div.

Could you elaborate this "Since adding 50 ohm resistors impacts the behavior it is likely an issue with the receiver termination detect where the device is detecting the disabled terminations of the TUSB7340 as enabled."?

We will try to collect waveform 1-2min after the device fails t enumerate.

What other things we can do to further debug whether it's a out of sync issue and something else?

That is very strange, the LFPS.polling should be 10 us,  not10 ms.

Please provide more scope plots.  Can you issue a software reset to see if it fixes the issue - sometimes this can be done by disabling and enabling the driver in Device Manager.

Hi JMMN,

We also bought a TI tusb7340evm board. It works well. Below is its waveform for your reference. The main difference is after it goes into the high frequecy signaling, it stays there.

Regarding your question, what our problematic borad's waveform looks like after 2min, it looks like below

And regarding the software reset, it does not help.

Any feedback?

Lastest update, Besides replacing AC coupling cap with 50 ohm resistor, shorting the AC coupling cap also greatly increases the successful rate. 

BTW, could you please change the status of this issue to Not Solved, right now is "TI thinks it solved" which is not true

Hello Junhua,

Which AC coupling cap pair is being shorted?  TX from 7340 or TX from the device?  TUSB7340 has been used in embedded designs in the past without any issues, but it appears that something about this device is causing the link training to fail.  Without high frequency scope probes and compliance testing, it will be difficult to determine root cause.

Regards,

JMMN

All four AC caps for TI's TX as well as the other chip's TX have been shorted.

Is it possible to try each TX pair separately and see if only one impacts the behavior?

Hi JMMN,

Yes, we just tried what you suggested. We only need to short one pair of the AC caps to get big impovement, which is the AC caps at TUSB7340's TX.

And we also measure the resistance look into the TX of TUSB7340 and the cypress's RX at power down. It turns out TUSB7340 has ~120 ohm in RX during power down, while the cypress chip's RX has >1Mohm resistance at power down.

Is this abnormal?

Thanks 

Update. If we measure with power, cypress chip's RX also has ~100 ohm resistance. So the input resistance should be OK. Not a suspecious point.

Hello Junhua,

It appears that the TUSB7340 is having difficulty detecting the receiver of the attached device, but I cannot determine why the issue is occurring.

Regards,

JMMN

Please post if there are additional updates.

Regards,

JMMN