Orin Nano USB0 and USB1 sometimes cannot reach USB 3.2 speed in R36.5.0

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
,
1

Hi,
I’m working on an orin nano with a custom board running R36.5.0.
Sometimes, USB0+DP0_TXD0/1 and USB1+USBSS_TX/RX fail to reach USB 3.2 speeds.
Please refer to the USB0 and USB1 schematics below.

image
image1394×187 21.7 KB

image
image1211×152 28.6 KB

image
image1638×666 84.4 KB

image
image1204×171 29.9 KB

image
image1401×542 67 KB

Code changes:

diff --git a/sources/hardware/nvidia/t23x/nv-public/tegra234-p3768-0000+p3767.dtsi b/sources/hardware/nvidia/t23x/nv-public/tegra234-p3768-0000+p3767.dtsi
index 6b3a8fae2..d94e7f780 100644
--- a/sources/hardware/nvidia/t23x/nv-public/tegra234-p3768-0000+p3767.dtsi
+++ b/sources/hardware/nvidia/t23x/nv-public/tegra234-p3768-0000+p3767.dtsi
@@ -90,6 +90,7 @@
                                        vbus-supply = <&vdd_5v0_sys>;
                                        status = "okay";
                                        usb-role-switch;
+                                       role-switch-default-mode = "host";
                                };

                                /* hub */

USB0 and USB1 can reach USB 3.2 speeds in R36.4.4 but they fail to do so in R36.5.0.
Did I miss anything?

dts.txt (322.2 KB)
dmesg.txt (62.1 KB)

Thx
Yen

3

— 🤖 This is an automated AI response. I’m here to help, but please verify important details! —

The issue you’re experiencing with USB0 and USB1 sometimes failing to reach USB 3.2 speeds on your custom Jetson Orin Nano board running R36.5.0 could be related to the changes in the device tree configuration or other system settings between R36.4.4 and R36.5.0.

Given the provided context, it seems like the problem might be related to the USB role-switch configuration. In the code changes you provided, there’s an addition of role-switch-default-mode = "host"; in the device tree configuration for USB0 and USB1. This change could potentially affect how the USB ports operate, especially if the role switch is not properly configured for USB 3.2 speeds.

To troubleshoot this issue, you might want to review the device tree configuration and ensure that it’s correctly set up for USB 3.2 operation on both USB0 and USB1. Additionally, checking the system logs (like dmesg) for any error messages related to USB could provide more insights into what’s going wrong.

It’s also worth noting that the Jetson Orin Nano’s USB performance can be influenced by various factors, including the quality of the USB cables, the power supply, and the system’s configuration. Ensuring that all hardware components are compatible and properly connected is crucial.

Since the issue doesn’t occur in R36.4.4 but does in R36.5.0, comparing the device tree configurations and system settings between these two versions might help identify the root cause of the problem.

For further assistance, it would be helpful to have more details about your custom board’s design, especially the parts related to USB0 and USB1, and any other relevant system configurations or logs that could shed more light on the issue.

I could not find clear support for the exact cause of the USB speed issue in the provided Jetson Orin Nano documentation. However, reviewing device tree configurations, system logs, and ensuring hardware compatibility are recommended steps for troubleshooting.

— We support team will also look into your issue to have further suggestions soon. please stay tuned. —

5

Hi

any updates?

Thx
Yen

6

Do you have equipment that is able to check the USB bus trace between rel-36.4.4 and rel-36.5?

7

Hi

No, we don’t have any usb equipment to trace usb bus.

Thx
Yen

8

Then I think it is hard for us to check what is wrong on a custom board without a trace.

9

Hi,

I found that changing the usb2-0 node to mode = "host" in dts allows USB0+DP0_TXD0/1 to consistently reach USB 3.2 speeds. Is it possible that there is an issue with the OTG logic in the USB driver?

  usb2-0 {
      mode = "host";
      vbus-supply = <&vdd_5v0_sys>;
      status = "okay";
  };

Thx
Yen

10

No, if you make a port as type A, then it could only work as host mode from the nature of hardware. Forcing it as OTG turns out to be have unpredictable behavior.

11

Hi,

Do you mean USB0 cannot be designed to support USB 3.2 in OTG mode? Is there any documentation I can refer to?

Thx
Yen

12

No, I mean the USB0 is the flash port so it should be designed as a OTG mode.

However, you make it as type A which could not be used as OTG by its hardware nature.

13

Hi,

Do you mean we should use a Type-C connector instead of a Type-A connector?

Thx
Yen

14

Hi,

This ticket actually has multiple issues

  1. For USB0, because this one has to be flash port. OTG is needed for it (ideally)
    From hardware aspect that only type C and micro B connector with correct design are able to support full OTG function. Thus, we suggest you should make USB0 as this kind. And need to have correct devicetree configuration.
    However, type C design is more complicated and might lead to other problems.

  2. For USB1, making it as host mode and type A is fine. However, you said even USB1 could reproduce issue. Which seems have nothing to do with your USB0 setting. Thus, you better checking if it is different issue on USB1.

15

Hi,

OK, I’ll focus on USB0 first.
If we use a Type-A connector and manually switch between host and device modes by echoing “host/device” into “/sys/class/usb_role/usb2-0-role-switch/role”, is it possible to encounter the issue where USB0+DP0_TXD0/1 fails to reach USB 3.2 speeds while in host mode?

Thx
Yen

16

It is still possible but the reason could be related to hardware signal quality. We have seen such case before.

Just to clarify. There are lots of reasons that could lead to USB speed downgrade. Without usb bus trace, generally it won’t be possible to debug on custom board.