USB3,0 Device only enumerated as USB2.0 on TX2 after powerup

Dear NVidia Team

We customized the device tree in JetPack 4.3 for our custom board. Now we face the problem, that one USB3.0 Port (Signals UPHY_RX1_P/N Pins C22,C23 and UPHY_TX1_P/N Pins G22, G23) does not work as expected. USB3.0 devices get recognized only as USB2.0 after power-on. If we reconnect the device, it is correctly enumerated as USB3.0, so overall our configuration should be ok. The corresponding USB2.0 Signals (USB3_P/N Pins G10, G11) are routed to the A-Type USB3.0 connector over a USB2.0 Hub. It seems that this leads to the strange behavior. The Hub is enabled by a GPIO (AA, 3).
We have already checked multiple different threads and tested many solutions, but sadly none of them worked. We tried adding ramp-delays to the regulator and turned the Hub on by hand after boot up via the GPIO. But always the device was not enumerated correctly.
Do you have any other suggestions what we could try?
Thank you.

For information, please check
Table 13. USB 2.0 Pin Descriptions
Table 14. USB 3.0, PCIe & SATA Pin Descriptions
and share which pins are used in the problematic Type-A port.

And is it specific to the USB device? Or happens to all USB devices?

Hi DaneLLL

For the problematic USB Type-A port we use the USB3.0 Signal pins PEX_RFU_RX+/- (G39,G40), PEX_RFU_TX+/- (D39, D40) and the USB2.0 Signals USB2_D+/- (B42, B43) which go over a hub. The mentioned pins in the first post are wrong, sorry for that.
It happens to all USB3.0 devices that we tested so far.
Thank you.

One possible reason is that VBUS may be turned on too early. We have seen similar issues:

Please turn VBUS on after booting to kernel.

As mentioned in the first post, turning on the VBUS after booting does not help. It has the same effect. When changing the GPIO to high, the device gets enumerated as USB2.0 device. When reconnecting the device, it again gets enumerated correctly as USB3.0 device. Do you have any other idea what to do?
Thank you.

Please refer to the guidance for tuning eye diagram to pass compliance test:
There is a hub connected and the hardware signal may need to be tuned accordingly.

Hi DaneLLL
We found a workaround. Unbinding the hub and then binding it again solves the problem:

sudo echo 1-3:1.0 > /sys/bus/usb/drivers/hub/unbind
sudo echo 1-3:1.0 > /sys/bus/usb/drivers/hub/bind

So basically we do not think that we have a compliance problem. We can use this workaround, but also appreciate other solutions. Thank you.

Kind regards

1 Like