TX2 NX USB0 can't found after flash

Autonomous Machines Jetson & Embedded Systems Jetson TX2
,
1

Hi,
This is a custom board. The board can be enter force recovery mode. And flash jetpack 4.6.6 successfully by usb0 communication.
Normally after power on to L4T OS, when connect usb0 to PC, the jetson should act as a gadget device and COM. But my Jetson shows nothing when usb0 connected to PC. Looks like this a usb0 communication issue.

Could you suggest how to fix it？

Thanks!

2

You have to configure the device tree setting to match your board.

This is a custom board. The board can be enter force recovery mode. And flash jetpack 4.6.6 successfully by usb0 communication.

This comment here does not prove anything. Recovery mode is a pure hardware event that no software is inolved. This flash can work does not mean your design or software are valid.

3

The usb0 only designed for debug port, same as nvidia devkit. So used the same device tree setting with devkit.

4

Please dump your dmesg first.

5

USB software needs to be fully correct. If you only have one port same as devkit but the rest of them are not, then it won’t work either. Device tree change is still needed.

6

Thanks Wayne!
There are 2 boards reported this issue after tested 15 boards. It’s more like a hardware issue, not device tree issue.
Tried to tune USB2.0 registers, no help. Maybe the still need to fine tune.
But the force recovery mode are always good. How to leverage the force recovery mode configuration to usb debug?

7

  1. Please just leave recovery mode alone… it has nothing to do with usb device mode for kernel…

  2. Please upload the dmesg first.

  3. If you think it is hardware problem, you could compare the hardware signal between these boards… We don’t know who you are and how you made your board, the comment you provided there does not help at all…

我直接用中文說明可能快一點…

  1. 不要太執著在recovery mode… 這個東西對你的usb device mode一點幫助都沒有. 你一直問這個只是在浪費時間

  2. 麻煩照我說的把你的dmesg先貼上來.

  3. 如果你認為是hardware issue就請你自己先比較一下你這幾片hardware在信號上有什麼差異. 我們不會知道你的板子怎樣設計. 這樣沒頭沒尾的敘述完全對現況沒什麼幫助.

8

dmesg_usbdebug_fail.txt (76.4 KB)
dmesg_usbdebug_good.txt (77.3 KB)
Attached. please help to take a look. thank you.

9

In your NG case,

[ 1.266107] tegra-xudc-new 3550000.xudc: USB charger detection disabled
[ 1.266114] tegra-xudc-new 3550000.xudc: vbus state: 0

In your working case,

[ 1.264349] tegra-xudc-new 3550000.xudc: vbus state: 1
[ 1.264356] tegra-xudc-new 3550000.xudc: device mode on: 0
[ 1.264471] tegra-xudc-new 3550000.xudc: active: 0 => 1

Looks like vbus_det pin signal is different that leads to different behavior.

This is same as what I said, you have to write your device tree to match your hardware design. Otherwise it is just random behavior.

10

it did lead us to check vbus_det pin. It’s hardware issue cause the vbus_det different behavior. Thank you so much!

1 Like