-71 error occurred on USB2 2.0 Port

[shinichiro.adachi]

We are working on custom carrier board for Jetson Nano module.
In the Linux Kernel based 4.9.140-tegra-32.4.2, sometimes -71 error occurred on USB2 2.0 Port.
After the error occurred, I reinserted USB device again and again, but the same error occurred.
Once this happens, it seems that it will not be resolved until Power-Reset the board again.

Starting kernel ...

[    1.211138] tegradc tegradc.1: dpd enable lookup fail:-19
[    1.717278] Host read timeout at address 545c00c4
[    1.777353] igb 0000:05:00.0: The NVM Checksum Is Not Valid
[    1.783066] igb 0000:05:00.0: force skipping EIO
[    1.998275] imx219 7-0010: imx219_board_setup: error during i2c read probe (-121)
[    2.005834] imx219 7-0010: board setup failed
[    2.034022] imx219 8-0010: imx219_board_setup: error during i2c read probe (-121)
[    2.041540] imx219 8-0010: board setup failed
[    2.123937] pca953x 0-0075: failed reading register
[    2.501110] cgroup: cgroup2: unknown option "nsdelegate"
[    3.755192] using random self ethernet address
[    3.789735] using random host ethernet address
[    4.163979] random: crng init done
[    4.167386] random: 7 urandom warning(s) missed due to ratelimiting
[    4.292629] using random self ethernet address
[    4.302378] using random host ethernet address

Ubuntu 18.04.4 LTS shin-desktop ttyS0

<- insert USB device to the port here.

shin-desktop login: [   13.474986] usb 1-3: Device not responding to setup address.
[   13.687332] usb 1-3: Device not responding to setup address.
[   13.898890] usb 1-3: device not accepting address 2, error -71
[   14.023425] usb 1-3: Device not responding to setup address.
[   14.235894] usb 1-3: Device not responding to setup address.
[   14.446897] usb 1-3: device not accepting address 3, error -71
[   16.255348] usb 1-3: device descriptor read/64, error -71
[   16.486862] usb 1-3: device descriptor read/64, error -71
[   16.839278] usb 1-3: device descriptor read/64, error -71
[   17.071268] usb 1-3: device descriptor read/64, error -71
[   17.183126] usb usb1-port3: unable to enumerate USB device
[   24.871617] usb 1-3: Device not responding to setup address.
[   25.083558] usb 1-3: Device not responding to setup address.
[   25.294899] usb 1-3: device not accepting address 6, error -71
[   25.419800] usb 1-3: Device not responding to setup address.
[   25.631540] usb 1-3: Device not responding to setup address.
[   25.842894] usb 1-3: device not accepting address 7, error -71

Ubuntu 18.04.4 LTS shin-desktop ttyS0

I did USB Compliance Test by usb_ehset_test for USB2 2.0 Port, but there was no problem.
Could you please tell me how to fix the problem?

[DaneLLL]

Hi,
Please look at
https://developer.nvidia.com/embedded/dlc/jetson-nano-product-design-guide
On default board, USB2-0 is a micro-B port running in device mode only. Pins 87/109/111 are connected. If your design is different, please share more information so that we can check and suggest next.

[shinichiro.adachi]

Hi DaneLLL, Thank you for your reply.

The port that having problem is USB2. Pins 121/123 are connected.
In our Custom Board, we connected a USB-HUB, but replaced with USB device directly for debug now.

Could you give me some advice about this problem? Thanks.

[DaneLLL]

Hi,
The default vbus-supply for usb2-2 is

                ports {
                        usb2-2 {
                                vbus-supply = <&p3449_vdd_usb_vbus2>;
                        };

Don’t see which pin being used as vbus in the layout. You may check if this is correctly configured.

[shinichiro.adachi]

Hi,

Don’t see which pin being used as vbus in the layout. You may check if this is correctly configured.

We have a VBUS GPIO (USB2_EN) connected at the end of USB_2-2.

However, the power supply of USB_HUB (V3_3_USB-HUB) is turned on with board power supply.

USB2_D_N/P => USB_HUB => USB-HUB_DN1_DP/DM => USB_PORT

USB_PORT is connected directly for debug now.

USB2_D_N/P => USB_PORT

VBUS of USB_PORT is always ON after board power-on, but the error occurs.
Since VBUS is always supplied, I think the cause is not the control of VBUS.

For p3449_vdd_usb_vbus2, it seems no GPIO control in the default EVK state.

	[sources/hardware/nvidia/platform/t210/porg/kernel-dts/porg-platforms/tegra210-porg-fixed-p3448-0000-a00.dtsi]

	p3449_vdd_usb_vbus2: regulator@10 {
		compatible = "regulator-fixed";
		reg = <10>;
		regulator-name = "vdd-usb-vbus2";
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		vin-supply = <&p3448_vdd_3v3_sys>;
	};

[DaneLLL]

Hi,
On default carrier board, it is usb2-0 + usb3-1 in pair to be connected to embedded hub. Yours is usb2-2 to be connected to embedded hub. The default setting p3449_vdd_usb_vbus2 does not fit the design. You may replace it with dummy regulator:

                ports {
                        usb2-2 {
                                vbus-supply = <&battery_reg>;
                        };

And do compliance test or try power cycle after booting to kernel:
https://elinux.org/Jetson/L4T/r32.3.x_patches
[Jetson Nano]Do USB2 compliance test on USB hub
[Jetson Nano]Power control

[shinichiro.adachi]

Hi,

            You may replace it with dummy regulator:

            ports {
                    usb2-2 {
                            vbus-supply = <&battery_reg>;
                    };

I replaced usb2-2’s vbus-supply from p3449_vdd_usb_vbus2 to battery_reg,
but USB -71 error was reproduced within 10 boot times.

[Jetson Nano]Do USB2 compliance test on USB hub

Jetson Nano USB2.0 Tuning Guide ~ Bus error (core dumped)

Hi, Jetson Nano devkit is with an external USB hub and have to follow the spec of running in test mode: [image] Please try attached test code. 1. Copy realtek_hub_test_mode.c to Jetson Nano. 2. sudo apt-get install libusb-1.0-0-dev 3. gcc -o test_mode realtek_hub_test_mode.c -lusb-1.0 4. sudo ./test_mode realtek_hub_test_mode.zip (761 Bytes)

Our USB hub is not realtek-hub(RTS5411S), but microchip(USB2514BT-I).
I think realtek_hub_test_mode.zip cannot use for our emmbedded hub.

And we already confirmed that no problem with usbhub.
Because we got same -71 error with following direct USB2_D_N/P connection.

USB2_D_N/P => USB_PORT

[Jetson Nano]Power control

USB Power control

Hi, On Nano, please download/extract the attachment and follow the steps: Copy realtek_hub_power_cycle.c to Jetson Nano $ sudo apt-get install libusb-1.0-0-dev $ gcc -o power_cycle realtek_hub_power_cycle.c -lusb-1.0 $ sudo ./power_cycle realtek_hub_power_cycle.zip (653 Bytes)

I checked realtek_hub_power_cycle.zip , realtek_hub_power_cycle.c.
It’s based on libusb_control_transfer() and sending usb packet to usb hub.
so it can’t use after occured -71 USB error,of course.

[DaneLLL]

Hi,
realtek_hub_test_mode.zip is based on USB spec and is supposed to work with all hubs. If you also see issue with direct connection, suggest you run direct compliance test to check/tune eye diagram.
https://developer.nvidia.com/jetson-nano-interface-tuning-and-compliance-guide-application-note

[shinichiro.adachi]

Hi,

If you also see issue with direct connection, suggest you run direct compliance test to check/tune eye diagram.

Thank you for your advice.
we set the registers with reference to
[Jetson Nano Interface Tuning and Compliance Guide: Test Mode Programming Sequence].

connection:

USB2_D_N/P => USB_PORT => USB-Dongle

script:

root@root-desktop:~# ./usb2_test.sh
2. Disable the auto-suspend for the controllers:

echo on > /sys/bus/usb/devices/usb1/power/control
echo on > /sys/bus/usb/devices/usb2/power/control

3. Set PP (Port Power) in Disabled state by XUSB_XHCI_OP_PORTSC* bit [9] = 0.
GEN_XUSB_XHCI_OP_PORTSC=0x603
MOD_XUSB_XHCI_OP_PORTSC=0x0403
/dev/mem opened.
Memory mapped at address 0x7fa3668000.
Value at address 0x70090480 (0x7fa3668480): 0x603
Written 0x403; readback 0x603
ReRead GEN_XUSB_XHCI_OP_PORTSC=0x80

4. Set RS (Run/Stop) bit in the XUSB_XHCI_OP_USBCMD bit [0] = 0.
GEN_XUSB_XHCI_OP_USBCMD=0x805
MOD_XUSB_XHCI_OP_USBCMD=0x0804
/dev/mem opened.
Memory mapped at address 0x7f9ee5e000.
Value at address 0x70090020 (0x7f9ee5e020): 0x805
Written 0x804; readback 0x804
ReRead GEN_XUSB_XHCI_OP_USBCMD=0x804

5. Wait for HCHalted (HCH) bit in the XUSB_XHCI_OP_USBSTS bit [0] = 1.
GEN_XUSB_XHCI_OP_USBSTS=0x1
ReRead GEN_XUSB_XHCI_OP_USBSTS=0x1

6. Set the xUSB USB2.0 Port Test Control Registers in PORTPMSCHS register to enable test patterns
GEN_PORTPMSCHS=0x0
TEST_PATTERN=0x50000000
/dev/mem opened.
Memory mapped at address 0x7f98f4b000.
Value at address 0x70090484 (0x7f98f4b484): 0x0
Written 0x50000000; readback 0x0
ReRead GEN_PORTPMSCHS=0x50000000

7. Disable Pad PD (Power Down) by clearing the XUSB_PADCTL_USB2_OTG_PADx_CTL_0_0 bit [27:26] = 0b’00.
XUSB_PADCTL_USB2_OTG_PAD=0xCD1010
root@root-desktop:~#

usb2_test.sh.txt (2.9 KB)

And first we checked the waveforms by logic analyzer.
However, as a result of the register operation, both USB D+/D- signals are now low like below.

In all test cases [Normal operations/Test J/Test K/Test SE0 NAK/HS Test packet/Force enable],the results were the same.

Could you tell me how to output test waveform? Thanks.

[shinichiro.adachi]

Hi,
we conducted “Test Mode Programming Sequence” in Jetson Nano EVK.
On default carrier board, we used usb2-0 + usb3-1.

root@root-desktop:~# ./usb2_0_test.sh

2. Disable the auto-suspend for the controllers:
   echo on > /sys/bus/usb/devices/usb1/power/control
   echo on > /sys/bus/usb/devices/usb2/power/control

3. Set PP (Port Power) in Disabled state by XUSB_XHCI_OP_PORTSC* bit [9] = 0.
   GEN_XUSB_XHCI_OP_PORTSC=0x2A0
   MOD_XUSB_XHCI_OP_PORTSC=0x00a0
   /dev/mem opened.
   Memory mapped at address 0x7fa8887000.
   Value at address 0x70090460 (0x7fa8887460): 0x2A0
   Written 0xA0; readback 0x2A0
   ReRead GEN_XUSB_XHCI_OP_PORTSC=0x80

4. Set RS (Run/Stop) bit in the XUSB_XHCI_OP_USBCMD bit [0] = 0.
   GEN_XUSB_XHCI_OP_USBCMD=0x805
   MOD_XUSB_XHCI_OP_USBCMD=0x0804
   /dev/mem opened.
   Memory mapped at address 0x7f98838000.
   Value at address 0x70090020 (0x7f98838020): 0x805
   Written 0x804; readback 0x804
   ReRead GEN_XUSB_XHCI_OP_USBCMD=0x804

5. Wait for HCHalted (HCH) bit in the XUSB_XHCI_OP_USBSTS bit [0] = 1.
   GEN_XUSB_XHCI_OP_USBSTS=0x1
   ReRead GEN_XUSB_XHCI_OP_USBSTS=0x1

6. Set the xUSB USB2.0 Port Test Control Registers in PORTPMSCHS register to enable test patterns
   GEN_PORTPMSCHS=0x0
   TEST_PATTERN=0x50000000
   /dev/mem opened.
   Memory mapped at address 0x7f99588000.
   Value at address 0x70090464 (0x7f99588464): 0x0
   Written 0x50000000; readback 0x0
   ReRead GEN_PORTPMSCHS=0x50000000

7. Disable Pad PD (Power Down) by clearing the XUSB_PADCTL_USB2_OTG_PADx_CTL_0_0 bit [27:26] = 0b’00.
   XUSB_PADCTL_USB2_OTG_PAD=0x4CD1010
   MOD_XUSB_PADCTL_USB2_OTG_PAD=0xcd1010
   /dev/mem opened.
   Memory mapped at address 0x7fa9868000.
   Value at address 0x7009F088 (0x7fa9868088): 0x4CD1010
   Written 0xCD1010; readback 0xCD1010

root@root-desktop:~#

But, result is same as custom board envirnment.
Both USB D+/D- signals are goes LOW.

I checked step by step, it seems stop waveform at “step4. set RS (Run/Stop) bit”.
And never re-output waveform again after that.

Could you clarify the following points?

1. we inserted USB device at “step1. Connect any USB device to the port”.
   So When should we remove the USB device?
   It seems already unplugged device at “step8. Plug in the test fixture to start USB2.0 eye diagram test.”

2. At what step is the USB signal re-output?

[shinichiro.adachi]

As I wrote in the POST below, it was found that the value of clock-related registers is different from the usual when a -71 error occurs on Kernel.
It is the CLK_RST_CONTROLLER_PLLU_BASE_0 register in Clock and Reset (CAR).

USB related clocks are sometimes unstable

We are working on custom carrier board for Jetson Nano module. On our custom board, sometimes 10-second timeout may occur during the detection of an embeded USB-HUB in L4T Cboot, as shown below. OK: [0002.962] xhci0: 64 bytes context size, 32-bit DMA [0003.002] usbus0: 5.0Gbps Super Speed USB v3.0 [0003.022] uhub0: <Nvidia XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 [0003.672] uhub0: 9 ports with 9 removable, self powered [0004.712] uhub1: <vendor 0x0424 product 0x2514, class 9/…

OK:
U-Boot # md 0x60006000
60006000: 00000800 1c93428a 00000000 028ec5d2    .....B..........
60006010: 80409171 020080c1 81f00228 00000000    q.@.....(.......
60006020: 20008888 80000000 20004444 80000001    ... ....DD. ....
60006030: 00000001 00000000 00000000 00000000    ................
60006040: 00000000 00000000 00000000 00000000    ................
60006050: 50000011 00000000 00000000 00000493    ...P............
60006060: 00000000 00000000 00005c00 00000010    .........\......
60006070: 00000000 00000002 00000000 00000000    ................
60006080: 00108002 00000002 40000000 08000000    ...........@....
60006090: 4c007d03 00000000 00000000 00000010    .}.L............
600060a0: 48115408 00000003 00030003 00040010    .T.H............
600060b0: 00803003 00000002 00000000 12000000    .0..............
600060c0: 4be11902 00020003 00000000 60000000    ...K...........`  //CLK_RST_CONTROLLER_PLLU_BASE_0
600060d0: 00211001 00000000 00000000 00040000    ..!.............
600060e0: 48003502 00040000 0e007d02 00006200    .5.H.....}...b..
600060f0: 00000000 00000000 00000000 00000000    ................

NG:
U-Boot # md 0x60006000
60006000: 00000800 1c93428a 00000000 028ec5d2    .....B..........
60006010: 80409171 020080c1 81f00228 00000000    q.@.....(.......
60006020: 20008888 80000000 20004444 80000001    ... ....DD. ....
60006030: 00000001 00000000 00000000 00000000    ................
60006040: 00000000 00000000 00000000 00000000    ................
60006050: 50000011 00000000 00000000 00000494    ...P............
60006060: 00000000 00000000 00005c00 00000010    .........\......
60006070: 00000000 00000002 00000000 00000000    ................
60006080: 00108002 00000002 40000000 08000000    ...........@....
60006090: 4c007d03 00000000 00000000 00000010    .}.L............
600060a0: 48115408 00000003 00030003 00040010    .T.H............
600060b0: 00803003 00000002 00000000 12000000    .0..............
600060c0: 4be12502 00020003 00000000 60000000    .%.K...........` //CLK_RST_CONTROLLER_PLLU_BASE_0
600060d0: 00211001 00000000 00000000 00040000    ..!.............
600060e0: 48003502 00040000 0e007d02 00006200    .5.H.....}...b..
600060f0: 00000000 00000000 00000000 00000000    ................

The value of PLLU_DIV seems to be different.

reg											addr		OK			NG
CLK_RST_CONTROLLER_PLLU_BASE_0				0x600060c0	0x4be11902	0x4be12502

Refer to [Tegra_X1_TRM_DP07225001_v1.3p.pdf]…

PLL_U must be properly configured in the Boot ROM. DO NOT change the parameters of
PLL_U while the unit is running. The same applies to the USB_PHY_PLL.

How does Boot ROM set the PLL_U value?
Why do PLL_U values sometimes differ?
Could you check this with internal team? Thanks.

[liumiao]

I met the same problem with you and did not get any suggestion except " try to find the difference of the design between custom carrier board and the develop board" .

Now I had to correct the register manually. just as a workaround.

[DaneLLL]

Hi,
Since we don’t have the custom boards, it is difficult to provide further suggestion without reproducing the issue. If you feel like it is something wrong in NVIDIA USB driver or firmware, please help check if you can reproduce it on default Nano devkit and share us the steps. So that we can reproduce the issue and do further check.

[liumiao]

I do not think the default Nano devkit is the ONLY RIGHT WAY to use nano board. in fact, the PLL issue is not only reproduce on my board , also on shinichiro.adachi 's.

In fact, both shinichiro.adachi and I found the register value is wrong even in Boot ROM, in the Boot ROM stage, All needed of the SKU from carrier board is power, I do not think I have any difference with devkit.

If any issue must be reproduce on devkit , then nvidia will admit it‘s a bug and begin to check it, I do not think it’s a responsible way!

I think nvidia can say “WE ONLY SUPPORT DEVKIT”！

[BARO]

We are using a hub usb tusb8041 and I have the same problem. I can’t see the USB hub.
May be is a problem with the signals and the design. Or the device tree is not ok to recognise it automatically.

[shinichiro.adachi]

Hi,

After a long investigation, we found the following situation on our Custom Board.
The value of PLLU_DIV seems to be normal if [CPU pin235:PMIC_BBAT] is high when the CPU is powered on.

In our board, we have an RTC battery connected to pin235.

When the RTC battery is connected, PLLU_DIV value is always normal.
When the RTC battery is not connected, the PLLU_DIV value is sometimes abnormal.

Finally, the our circuit has been modified so that power is always supplied
to PMIC_BBAT before powering the CPU Module.

So far, we have not had a USB -71 error in modified circuit.

This is the workaround in our case, not the official view.

If you solve it, please let me know what the cause was.

[sysopinit]

Has there been any progress on finding the actual cuase and a proper resolution for this issue? We have also developed a custom carrier and have encountered the same issue. As others have suggested, the rtc battery somehow keeps the usb from crashing.

[kayccc]

Hi sysopinit,

Please help to open a new topic for your issue. Thanks