Only USB 2.0 working (no USB 3.X) (USB-C, PD Controller)

[tobias.johansson1]

Hello. We are having issues with getting the USB 3.X to work on our custom carrier board for the AGX/Xavier. USB 2.0 works as intended - but devices never get enumerated/assigned the USB 3.X root hub.

lsusb -t output with a USB-C SanDisk flash drive (verified on dev-kit to appear as USB3.X) in the port:

/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 10000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
|__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M

dmesg output from inserting flash drive (leading to it being recognized and enumerated as USB 2.0/high-speed):

[ 1006.884868] tegra-xusb 3610000.xhci: exiting ELPG
[ 1006.892554] tegra-xusb 3610000.xhci: Firmware timestamp: 2020-09-11 16:55:03 UTC, Version: 60.09 release
[ 1006.894174] tegra-xusb 3610000.xhci: exiting ELPG done
[ 1006.897288] usb usb1: usb_suspend_both: status 0
[ 1007.629146] usb 1-3: new high-speed USB device number 3 using tegra-xusb
[ 1007.653868] usb 1-3: New USB device found, idVendor=0781, idProduct=55a4
[ 1007.654244] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1007.654308] usb 1-3: Product: SanDisk 3.2Gen1
[ 1007.654367] usb 1-3: Manufacturer: USB
[ 1007.654437] usb 1-3: SerialNumber: 0401093c3094021efa8c07340a5bbbbdf07e724a777dfdbc97718b7fd68388ca7a8200000000000000000000dfc6fa8cff076e18a455810796acebd4
[ 1007.664341] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 1007.665254] scsi host0: usb-storage 1-3:1.0
[ 1008.492596] usb usb2: usb_suspend_both: status 0
[ 1008.680160] scsi 0:0:0:0: Direct-Access USB SanDisk 3.2Gen1 1.00 PQ: 0 ANSI: 6
[ 1008.681851] sd 0:0:0:0: [sda] 60125184 512-byte logical blocks: (30.8 GB/28.7 GiB)
[ 1008.683078] sd 0:0:0:0: [sda] Write Protect is off
[ 1008.683199] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 1008.683685] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
[ 1008.695977] sda: sda1
[ 1008.698942] sd 0:0:0:0: [sda] Attached SCSI removable disk

For simplicity (just to get it working), only one USB port (1 USB2.0 + 1 USB3.X combo) is used for now.

USB 3.X pins used: B16, B17, K16, K17 (UPHY_RX6 and UPHY_TX6)
USB 2.0 pins used: A10, A11 (USB2_P and USB2_N)

This leads to: usb3-0 and usb2-2

DTS:

xusb_padctl: xusb_padctl@3520000 {
status = “okay”;

  pads {
  	usb2 {
  		lanes {
  			/* EXT USB-C (PORT 2) */
  			usb2-2 {
  				nvidia,function = "xusb";
  				status = "okay";
  			};
  		};
  	};
  	usb3 {
  		lanes {
  			/* EXT USB-C (PORT 2) */
  			usb3-0 {
  				nvidia,function = "xusb";
  				status = "okay";
  			};
  		};
  	};
  };

  ports {
  	/* EXT USB-C (PORT 2) */
  	usb2-2 {
  		mode = "host";
  		vbus-supply = <&battery_reg>;
  		status = "okay";
  	};
  	/* EXT USB-C (PORT 2) */
  	usb3-0 {
  	        mode = "host";
  		nvidia,usb2-companion = <0x02>;
  		status = "okay";
  	};
  };

};

tegra_xhci: xhci@3610000 {
phys = <&{/xusb_padctl@3520000/pads/usb2/lanes/usb2-2}>,
<&{/xusb_padctl@3520000/pads/usb3/lanes/usb3-0}>;
phy-names = “usb2-2”, “usb3-0”;
nvidia,xusb-padctl = <&xusb_padctl>;
status = “okay”;
};

USB PD Controller is verified to take care of flip correctly etc.

Any clear mistakes so far, or more information you would be helped by?

Thanks

[WayneWWW]

Sorry that your description is not clear enough for us to understand your design.

Is there any PD controller for your type C or not? Did you ever read the original device tree of our Cypress PD controller in default BSP? We have another node under i2c to handle the role switch.
From what I saw, your device tree does not include that part.

[tobias.johansson1]

Hi, thanks for the response.
Yes, there is a PD controller for Type C (a TI TPS65988).

dts section for PD controller:

i2c@3160000 {
tps6598x_1: tps6598x_1@20 {
compatible = “ti,tps6598x”;
reg = <0x20>;
cd-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(P, 1) /* H53 #USB_PD_INTRUPT_1V8*/
GPIO_ACTIVE_LOW>;
status = “okay”;
};
tps6598x_2: tps6598x_2@24 {
compatible = “ti,tps6598x”;
reg = <0x24>;
cd-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(P, 1) /* H53 #USB_PD_INTRUPT_1V8*/
GPIO_ACTIVE_LOW>;
status = “okay”;
};
};

Sorry. What I meant was that we have verified aldready that the PD controller flips/toggles the Type-C Redriver Switch (TI TUSB1042) in the right way, so that the right RX/TX signals are routed from the contact on the board to the AGX/Xavier pins depending on the direction/orientation of the Type C connector. The PD controller functions as intended as well for the PD negotiation etc - but except for the “flip”/orientation, it “has nothing to do with USB 3.X not working”.

Also, just to be clear: No Data or Power Role switching functionality needed - only Host/Source (as of now).

So the issue is: We are unable to get devices to be detected as USB 3.X devices - they always end up on the USB 2.0 root hub.

[WayneWWW]

Could you share the full dmesg as text file?

[tobias.johansson1]

Absolutely. See attached files (one is a clean boot without any USB device connected, and one is a clean boot with a verified USB 3.1 Type C flash drive connected).
dmesg_no_device.txt (85.7 KB)
dmesg_device_connected_at_boot.txt (87.5 KB)

[WayneWWW]

Could you also attach the finalized dts file converted from dtb? Thanks.

[tobias.johansson1]

Here is the dts:
output.dts (213.5 KB)

Thanks

[WayneWWW]

Hi,

1. Please help dump usb bus trace if you have equipment.

2. If you don’t have such test tool, please go to kernel/kernel-4.9/drivers/phy/tegra/xusb.h#519 and change the “dev_dbg” to “dev_err” and share us the log.

static inline void padctl_writel(struct tegra_xusb_padctl *padctl, u32 value,
unsigned long offset)
{
dev_dbg(padctl->dev, “%08lx < %08x\n”, offset, value);
writel(value, padctl->regs + offset);
}
static inline u32 padctl_readl(struct tegra_xusb_padctl *padctl,
unsigned long offset)
{
u32 value = readl(padctl->regs + offset);
dev_dbg(padctl->dev, “%08lx > %08x\n”, offset, value);
return value;
}

[tobias.johansson1]

Hi, and thank you.

Sorry, no such equipment or test tool. So have changed the code requested and here are the new dmesg logs (same as before, one clean boot with and one without the USB device connected).

dmesg_no_device_xusb_dbg.txt (89.7 KB)
dmesg_device_connected_at_boot_xusb_dbg.txt (90.3 KB)

[WayneWWW]

Hi,

We have checked the log with usb software team. The log looks fine. From software aspect, there is no error.

There is a need to capture usb bus trace for next step.

[WayneWWW]

Also, since this is type C, have you checked the connection with both side?

[tobias.johansson1]

First of - Type C, yes I have, I have tested both orientations (and other verified USB 3.X-devices as well) - but good question.

Attached are an extract from dmesg from inserting and removing the flash drive, changing orientation of it and then inserting and removing it again.

dmesg_extract_usb_c_both_ways.txt (17.2 KB)

In regards to “USB bus trace for next step” - could you elaborate in what you/I would need - are we talking soldering on probes on the diff pairs between the Redriver Switch and the AGX/Xavier, or on the D+/D- USB 2.0 diff pair - or?

I have managed to get a dump of the USB transfer of inserting the flash drive using tcpdump, usbmon and wireshark with both the USB 3.X root hub and the USB 2.0 root hub if that is of interest (.pcap file).

Attaching them just in case (aquired with tcpdump -i usbmonX -w .pcap and then inserting the flash drive):
inserting_flash_drive_usb_2_root_hub.pcap (246.8 KB)
inserting_flash_drive_usb_3_root_hub.pcap (8.3 KB)

[WayneWWW]

Hi,

Sorry that usbmon does not provide usb bus trace. What we need is the hardware eletrical handshake.

Need something like USBProtocolSuiteSW from Teledyne LeCroy.

[tobias.johansson1]

Hello, sorry for the delay - could not get a hold of the equipment you mentioned, but have finally managed to trace electrical handshake using an oscillocope (Rohde & Schwarz,16GHz, 40 GSa/s).

Note 1: I may have failed to mention that we are using the “AGX Industrial” version.

Note 2: Probes soldered just before reaching AGX connector on SSRX+/- and SSTX+/-. No chips or electronics between probing position and AGX pins. B16, B17, K16, K17 (UPHY_RX6 and UPHY_TX6)

Trace from when inserting flash drive in USB-C connector.
Channel 1/Yellow: TX (From AGX)
Channel 2/Green: RX (To AGX)

From what I can see, the TX is continuously sending LFPS bursts. While the device/RX sends 16 LFPS bursts before transitioning to what i believe to be the “training sequence” - which seems to be all according to specification/standard.

Looks a lot like scenario of a “failed Training Sequence” in image below, taken from: Microchip Lightning Support

A more zoomed out view of the same trace as above. The TX continuously sends these “LFPS bursts” for exactly 360 ms, before giving up and transitions to what looks like one of Compliance Mode/CP 13, -14 or -15. (Which also should be according to standard, if TX does not recognize a device within 360 ms). Notice however how the device begins its LFPS bursts “well before” the 360 ms cutoff time.

Image below taken from: https://download.tek.com/document/USB_3.1_what_you_need_to_know_ref_guide_61W_61235_0_1.pdf

So, it seems like the AGX fails to sense that the device is present/is sending the 16 LFPS burst - any idea in how to proceed/solve this issue?

Thanks

[WayneWWW]

Hi,

Some questions here

1. Is every device showing same waveform behavior as what you saw? Please make sure that device can work fine on devkit first.

2. Will it work if limit the speed to gen1?

[tobias.johansson1]

Hello. I wanted to let you know that we found the issue and have fixed it. The issue was that we did not have the capacitors on the RX line between the USB-hub and the AGX.