TUSB7340: Problems detecting USB devices

HI David:

  Can you take waveform for 3.3v , 1.1v and GRSTz signal during power up?

Regards

Brian

Hi Brian,

here is the power up sequence: red track is 3.3V, blue is 1.1V, green is GRST

Regards

Davide

Hi Davide:

  Can you add 2uf cap on GRSTz?

Best

Brian

Hi Brian,

with 1uF:

with 2.2 uF:

the problem is still present in both cases.

Regards

Davide

Can you send schematic to review?

Best

 Brian

Brian,

the USB3 section:

1.1V power section:

and GRSTz:

USB3_RST is a digital output provided by an ARM microcontroller that we can  connect to TUSB7340 GRST. Currently this signal is connected to the PG output of 1.1V regulator.

Thanks

Davide

Hi Davide:

   I didn't see any issue for schematic.

1:  can you remove EEPROM is installed?

2:  Can you check XIn 48Mhz clk and PCIe clk if meet below timing spec?

Best

Brian

Hi Brian,

1:EEPROM is not installed

2:This is the clock starting sequence:

(Blue:3.3V, Red:GRSTZ, Green: PCIe refclk, Brown: 48Mhz clk)

PERST is controlled by the single board computer, and it is deasserted much late in this sequence ( >3 s.) 

The 100Mhz clock is generated by the single board computer and it's distributed on the VPX bus. We also have the possibility to use a local 100MHz oscillator for PCIe clock.

I also tried to use the local clock, but in this case the host controller is not detected on PCIe bus. The only difference with respect the distributed clock is that it starts about 6 ms after 3.3V is stable, while the distributed clock starts immediately at power up.

Regards

Davide 

Hi Davide:

  for windows, did you try to use  TI driver  at TI.com?

Best

brian

Hi Brian,

yes, we installed only SLLC448 — TUSB73x0 xHCI Filter Driver for Win8/8.1/10, downloaded from TI.com.

Thanks

Davide

HI Davide:

  Can you try with windows default xHCI redriver?

Best

Brian

Hi Brian,

no changes when removing the TI driver, and leaving only the standard W10 XHCI driver

I think the issue is on USB side, not on PCIe side. 

In my previous description I missed a detail: ports 1 and 2 (that are the only used in our design) are not directly connected to the USB3 connector. We have a TUSB522PI redriver immediately before the USB3 connector. This is the schematic:

In the actual configuration, R108, R111, R113, R115 and R117 are not mounted: when the device is recognized (in Linux) it works at USB3 speed, so I suppose that equalization / deemphasis inputs are set correctly. We have already used this redriver with no issues in the past  (with different host controllers).

The problem seems to be in device initialization. 

As I wrote, if an USB device is already connected at startup, this seems to help the controller to initialize correctly

Could the redriver have some  influence in this behavior?

Regards

Davide

Hi Davide:

    how long is the trace between  port1/2 to TUSB522, maybe the EQ setting is not right.

  I also noticed,  TPS62825A   is  DC converter which switching at  2.2Mhz, this noise  could affect internal PLL  performance. You need to add   Ferrite bead at least for DC converter. 

Regards

Brian

Hi Brian,

the traces between the redriver and USB3 connector are about 15 mm long. But we have to manage a 0.5m cable connected to such ports.

We used the same EQ settings and component placement in older designs where we had a similar signal path, and they worked fine. The new entry in the current design is TUSB7340.

Regarding the DC/DC converter, do you mean adding a ferrite between the DC/DC output and the TUSB7340 1.1V power lines? We have not the physical space to do this in the current PCB revision. I could try to remove TPS62825A and connect externally an 1.1V LDO in place of it.

Regards

Davide

Davide:

   Do  you know what is the loss at 2.5Ghz for the cable?

    It worth to try with external LDO.

Best

Brian

any more update?

Best

Brian

Hi Brian,

still have to try it with an external LDO. 

I plan to do this in the next few days. I'll update you ASAP.

Thanks, 

Davide

Git it.

Best

Brian

Brian, 

tested with a 1.1V LDO. Same behaviour.

The problem seems to occurr as soon as an USB device is plugged into one of the TUSB7340 ports if the OS starts without any device connected. But if at least one device is already plugged at boot time, then it will be detected correctly and also the other ports will work fine (at least under Linux).

Could this be related in some way to the following problem described in errata doc. SLLZ067B? 

"Accesses to the PORTSC or PORTPMSC registers of a port that has been disabled
via the PORT(x)_DIS bit at PCI configuration address 0xE0 may cause the
controller to become unresponsive."

Regards

Davide

Did you  try to control PORT(x)_DIS bit?

Best

Brian

Hi Brian,

I tried 

setpci -s 08:00.0 E0.L

and the result is 00000000, both before and after the error "xHCI host controller not responding, assume dead" appeared on dmesg output.

so it seems that all the PORT(x)_DIS bits are reset (all ports enabled) when the error occurs.

At this point, the only relevant difference with TI's reference design is TUSB522 redriver. 

Even if I can't understand how this can work properly if the USB device is already attached when Linux boots.

Regards
Davide

Let's back to TUSb522p setting:

what is the loss for the cable? the cable is between TUSb522P to connector?

Best

Brian

The USB3 connector is placed about 15mm from TUSB522, soldered directly on the PCB.

The cable is connected externally. It's a standard COTS  USB3 extension cable (plug/receptacle), i don't know the losses. But it worked fine with any other USB3  port i tested with it.

Anyway the problem is the same also if I connect the USB device directly to the PCB connector, without a cable.

If this behavior is related to the redriver, I think the problem is in the section between controller and redriver, not in the one between redriver and connector/cable.

Rgds

Davide

Can you test any other USB3 device directly to USB connector , so there is no cable involved?

Best

Brian

Brian, already done. There's no difference. With or without an external cable it behaves the same.

Davide

do you have USB analyzer to take USB trace between USB connector and testing device?

Regards

Brian

Brian, unfortunately we don't have an USB protocol analyzer available.

Maybe we could get an USB2.0 analyzer. Do you think it could it be enough?

Davide

does USB2 device works fine?

Best

Brian

No, the behaviour is the same with both USB2 and USB3 devices.

Regards

Davide

So it may not USB3 redriver issue, let me think about it over the weekend.

Best

Brian

Hi Brian,

here are some news: I tried to completely isolate the redrivers by removing coupling capacitors on both RX and TX lines towards TUSB7340. Doing so, the superspeed lines are left floating, and only the USB2 is routed to the connector.

Same behaviour, an USB2 pendrive is correctly detected only if it is already connected at boot time. So I can confirm that it's not a redriver issue.

Note that this happens also by simply rebooting Linux. In this case GRST is not asserted, because 1.1V power is already present. Only PERST is asserted when the single board computer reboots.

Looks like the controller goes in some kind of unrecoverable state if there are no USB devices attached when PERST is de-asserted.

We also have a COTS XMC module based on TUSB7340 controller. This module works fine with our single board computer, both in Windows and in Linux. I noticed that such module has the EEPROM installed, but we don't know its content.

Is there any register setting that can be programmed in the external flash, that could be related to our issue?

Regards,

Davide

Brian, I have to correct  my last post.

When I reboot from Linux, neither GRST nor PERST are asserted. So there is not an hardware reset of the device.

But I suppose that it is re-initialized by BIOS via PCIe registers.

Something must be different in this phase depending on  whether we have an USB device connected or not.

May it be an ACPI  power management issue?

Davide 

Hi Davide:

  Do you have EEPROM file for XMC module ?

  Did you try to  totally power down the system  and power on with no device connected?

Davide Calza said:

May it be an ACPI  power management issue?

   You may just disable  ACPI and try .

Regards

Brian

Brian, 

•  We don't have the EEPROM file for the XMC module. It's a COTS, so we don't have technical details about it
• At the first power-on, the behaviour is the same as after a reboot. TUSB7340 will work only if at least one USB device is already plugged when system starts booting.

I already tried to change some  BIOS ACPI settings with no results, but actually I don't  know which of these settings might affect the TUSB7340's operations.

Regards

Davide

Maybe I can send you an EVM to test with your system to see if has the same issue.

Are you in US?

Best

Brian

Thanks Brian, we already bought a TUSB7340 EVM to evaluate Linux support. 

Unfortunately we can't try it in our current project, because it is based on VPX architecture, while the EVM needs a standard PCIe x1 connector.

Meanwhile I managed to read the EEPROM from our working XMC module, but it seems to pre-load default values in all registers, except for subsystem ID and vendor ID, that are customized.

Anyway, comparing the TUSB7340's registers of our board and the XMC module immediately after boot, I found some differences in PCIe latencies settings and ASPM support. In our board those values are different from the default value they should have after a reset. 

I'm trying to understand when these registers are overwritten in the boot phase. Also I would try to install an EEPROM in our board with the default registers values to see if something changes. 

Regards

Davide

ok, please update once you complete the test.

Best

Brian

Brian,

I read in an old thread on this forum that there is a flash burning software to program the connected EEPROM directly with TUSB7340:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/496678/flash-burner-program-for-tusb7340

Is that software still available? It would be very useful for us in production phase to avoid programming of the EEPROMs before to mount them on the PCBs.

Thanks

Davide

Hi Davide:

     We only have hub EEPROM tool which go though USB connection, we never get EEPROM tool for host the above E2E ticket mentioned.

Best

Brian