USB 3.0 HDD fails with EPROTO on custom carrier board (no hub IC / redriver)

Environment

  • Jetson Orin Nano 8GB
  • JetPack 6.2.1 / L4T R36.4.4
  • Custom carrier board (derived from P3768 reference design)
    • Main differences from the reference:
      (1) Port 1: USBSS0_* routed directly from Jetson to USB-A (no USB 3.0 hub IC)
      (2) Port 2: USBSS2_* (unused in the dev kit) additionally allocated to a USB-A connector
    • Standard passive components between SoC and connectors (AC coupling capacitors, TVS diodes, VBUS power switch, etc.) are implemented
    • Device tree:
      • Port 1 (USBSS0): uses the P3768 reference DT configuration unchanged
      • Port 2 (USBSS2): custom DT modification applied to enable usb3-2 lane (added status = "okay" with phandle on xusb_padctl/pads/usb3/lanes/usb3-2, status = "okay" and nvidia,usb2-companion = <2> on xusb_padctl/ports/usb3-2, and added usb3-2 to phys / phy-names on the xHCI node)

Symptom

The issue occurs on Port 1 (USBSS0). On the same Port 1:

  • USB flash drive: Works normally at SuperSpeed (5 Gbps)
  • USB 3.0 bus-powered HDD: Briefly attaches at SuperSpeed, then disconnects within a few seconds and enters a loop of device not accepting address N, error -71 (EPROTO)

Port 2 (USBSS2) works normally with the same HDD at SuperSpeed.

Even during the failure on Port 1, the xHCI PORTSC register reaches Link:U0 PortSpeed:4 (USB 3.0 link established), and EPROTO occurs in the subsequent address setup phase.

We directly probed the OUT pin (VBUS) and FLG (fault) pin of the USB power switch IC (AP22811AW5-7) with an oscilloscope. VBUS remained a clean, stable 5V during the failures, and FLG was never asserted low (overcurrent protection never triggered). We therefore believe this is not a power-related issue.

Goal

To achieve stable USB 3.0 operation with the HDD. Hardware modifications are acceptable.

Could you advise on the best approach? Thank you in advance.

Is same HDD working fine when putting it on NV devkit?

Unfortunately we do not have an NVIDIA Developer Kit on hand.

We need to get the verification result on devkit to triage whether it’s HW or SW issue.