On the Jetson Orin Nano DevKit Carrier Board EVM, the Type-C USB port speed is detected as USB 2.0

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi all.

We are currently using the Jetson Orin Nano DevKit Carrier Board EVM to test Type-C behavior. With a notebook PC as the host and using the USBTree tool, when the Type-C cable is connected to the notebook side first, then the EVM is powered on and boots into the system, and the Type-C port is plugged in afterward, there is a chance that the USB 3.0 high-speed signal cannot be detected on the notebook side in USBTree, and the connection is downgraded to USB 2.0 speed.

Test Condition:

Host : DELL Latitude 3410 with Type-C port

Device : Jetson Orin Nano DevKit Carrier Board EVM

Cable : Pasidai TBT4 cable 1.5m

F/R : 3/10

Test steps :

  1. Bootup Jetson Orin Nano DevKit Carrier Board EVM by DP display into the sytem.
  2. Plug type-C cable onto the EVM type-C port.
  3. Check the USBTree tool at host NB, we will find out this issue is reproducible.

Is there any one can explain this behavior ?

Is it OK or not, is this can be fixed ?

EVM
EVM1853×600 233 KB

Thanks ~

BR.

Hacken

3

Just want to clarify the problem. Are you saying that you saw Jetson is a USB2 device from your host PC?

4

Hi Wayne.

Yes, as you mentioned, on the host PC (NB) side, we will see the Jetson change from a USB 3.0 device to a USB 2.0 device.

There is a probabilistic behavior where the device initially enumerates as a USB 3.0 device, but after several plug-in and unplug cycles, it drops to a USB 2.0 device.

5

Which Jetpack version is in use?

6

Hi Wayne.

Jetpack v6.2.1

9

Hi Wayne.

Is there any internal update may share with us about this ?

Thanks ~

10

Hi,

We could reproduce this issue. Still checking this internally.

11

Hi Wayne.

Is there any improve on this item ?

Please share with us if any update.

Thanks ~

12

Hi,

We are still checking this issue internally.

The issue would be gone when we try to use analyzer to root cause. Thus, we need other methods to reproduce this.

13

Hi,

We notice that using better quality of USB cable could not reproduce this.

Could you also test with better quality of usb C cable?

14

Hi Wayne.

It’s the same status as mine, I can’t reproduce the issue by several TBT cables.

And may you provide which cable you tested PASS with us and we want to try again.

Thanks ~

15

It is a USB cable from the Lecroy USB analyzer.

16

Hi Wayne.

Got you and maybe it’s not a good choice for customer to chenge different cable if they already hasve some own cables on hand.

If if the customer side catch this issue and return issue back, we still need a good solution for them..

May you try another way to analysis this issue or what we can try if any other way ?

Thanks ~

17

Hi,

It is related to hardware signal quality issue. We still have internal discussion about this but I don’t think there would be any solution coming out soon.

19

Hi Wayne.

This does indeed look very close to a signal integrity issue. However, even cables that have passed MFi certification still have a chance of exhibiting this problem. We would like to know whether there have been any recent updates or progress from internal discussions.

Thanks ~

BR.

Hacken

20

Hi Wayne.

Is there any new update on this ?

If any information update, please share with us.

Thanks ~

BR.

Hacken

21

Hi NV Team,

Could you please provide an update? This is the last pending item we need to close the case. Your prompt reply would be greatly appreciated.

23

We already tested this issue before and confirmed this issue only happen on some cables but not every of them.
The suggestion here to switch cable seems to be something that we already confirmed.