Hi DaneLLL,
Just to add to this (though it was mentioned earlier)…
- Protocol Specific: This issue ONLY occurs with USB 3.2 Gen2 (10Gbps). USB 3.2 Gen1 (5Gbps) devices work perfectly without any hangs.
- Physical Interface Bypass: If we use a Type-C to Type-A cable and only perform hot-plugging on the Type-A side, the issue disappears.
- Hardware Validated: * SI (Signal Integrity): Fully measured and PASS at 10Gbps.
- CC Analysis: Compared the CC logic sequences with the NVIDIA EVM board; the behavior is identical.
- Recovery Method: Once the deadlock occurs, the port remains “dead” (no function) until:
-
Option 1: Manually unbinding/rebinding the xHCI driver via terminal: echo "3610000.xhci" > /sys/bus/platform/drivers/tegra-xusb/unbind echo "3610000.xhci" > /sys/bus/platform/drivers/tegra-xusb/bind
-
Option 2: A full system reboot.
It seems unrelated to the hardware design, as the issue can be resolved without a reboot. Is there any other information we can provide to assist with your analysis?
Hi,
The issue seems to be in PD controller. Looks like it doesn’t inform our roothub the device is removed in the condition. Would suggest check it. If it communicates with our roothub through i2c, please check if there is i2c transfer in the condition.
You may check how PD controller works on our developer kit.
Hi DaneLLL,
Attached are the PD sequences for both USB 3.2 Gen1 and Gen2. As shown in the waveforms, the INT, VBUS, ID, and CC signals are identical and show no anomalies during plug/unplug events.
Key points to consider:
-
Hardware Consistency: The PD controller’s notification to the SoC is functional, and dmesg confirms the OS receives the state change.
-
Protocol Specificity: If this were a PD notification issue, USB 3.2 Gen1 (5Gbps) should also fail. However, the deadlock ONLY occurs with Gen2 (10Gbps).
-
Driver Recovery: Since an unbind/bind of the tegra-xusb driver resolves the hang without a hardware reset, the issue appears to be within the xHCI/PHY state machine during Gen2 transitions.
Could you please help investigate why the controller enters this state specifically at 10Gbps?
Hi,
The VBUS status in U3 Gen2 UnPlug scope looks not clearly drop from high to low. Is there a chance to make improvement on this? It stays between high and low for a period and then goes to low.
And if you feel like it is an issue in our USB FW, please try to replicate it on developer kit, and share us the steps. We can set up Orin Nano developer kit and check. We have done SQA test cases on developer kit for each Jetpack release, so the FW is supposed to be stable for most use-cases.
Hi,
Please help dump the register after error happened.
→ 0x3610440
Hi NV Team,
Two update as below [NVIDIA EVM (FUSB301) V.S. Our Board (TUSB3221)]
1. Hardware Logic Validation
We physically disconnected the INT pin from the TUSB3221 and manually configured the port to Fixed Host Mode via software commands(echo host > /sys/class/usb_role/usb2-0-role-switch/role).
Result: The USB 3.2 Gen2 deadlock completely disappeared, and the port functioned perfectly across multiple hot-plug cycles.
This experiment successfully excludes TUSB3221 hardware failure or SI (Signal Integrity) issues as the root cause.
2. Observed Behavioral Discrepancy (INT Signaling):
NVIDIA EVM (FUSB301):** Triggers the INT signal twice during a plug event. This multi-stage notification likely ensures VBUS and CC logic stability before data link training.
Our Board (TUSB3221): Triggers INT only once due to its autonomous nature.
Conclusion: Since the issue is resolved by fixing the mode and bypassing the dynamic interrupt handling, we suspect a Race Condition in the xHCI/PHY driver’s state machine specifically when handling 10Gbps transitions with single-interrupt CC controllers.
Do you have any suggestions or recommended debug steps for this finding?
Hi,
Do you mean INT signaling of FUSB301 is wrong? It should not trigger the plugin event twice?
Hi @stephen.ting
As previous comment, please dump register value 0x3610440 after you reproduce issue. It would reveal some info.
Hi NV Team,
Register dump info as below.
Hi DaneLLL,
Thank you for the response. To clarify, I don’t mean that the FUSB301’s dual-INT signaling is “wrong.” Rather, my point is that different CC Logics have different interrupt behaviors. Our goal is to determine what software or driver parameters should be adjusted to accommodate an autonomous controller like the TUSB3221. Of course, the premise remains that the dual-INT observed by the NV EVM represent reasonable behavior.
