Jetson AGX Xavier USB Not Detected

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

I previously flashed the Xavier with JetPack 4.2 through the SDK Manager on Ubuntu 18.04 and all the USB-C ports were working as I plugged my keyboard in to set up the device. Everything I needed was installed on the device and I turned off the device until the next morning.

I then power the device back on the next morning and plug in a Gemalto Key, only to realise it is not receiving any power and the LED that normally turns red isn’t powered. If I remove the power from the Xavier completely and then plug it back in with the Gemalto Key in, I see that the red light shows up for about a second and then turns off and receives no power after that.

The strange part is that now I can no longer use any keyboard or USB device on the Xavier. I can however connect the USB-C to a laptop where I can flash the device, however when it comes to setting up the operating system, when I try and plug a keyboard in to do this, it is not recognised and I can’t proceed.

Any idea what could be causing this?

2

Does serial console work? If so, then you might get a boot log from that to post.

3

Currently getting no devices in /dev/ showing up when plugging it into a Linux machine but getting Bus 001 Device 024: ID 0955:7019 NVidia Corp. from lsusb

4

Also note, that when I could access the machine over ssh (before I reset the device) there were no USB devices shown from lsusb (not even USB controllers as I’ve seen previously) on the Xavier.

However, plugged in the HDMI and received the following errors:

tegra-xusb 3610000.xhci: USB2 port0 has OTG_CAP
tegra-xusb 3610000.xhci: USB3 port2 has OTG_CAP

tegra-i2c c2400000.i2c: no acknowledge from address 0x69
bmi160 1-0069 bmi_i2c_rd ERR: 0x00
bmi160 1-0069 bmi_init _id_i2c ERR
Could not get extcon-dev /xudc@3550000:vbus(0)
bmi160 8-0069: nvs_vregs_init vdd err=-19
bmi160 8-0069: nvs_vregs_init vdd_10 err=-19
Could not get extcon-dev /xhci@3610000:id(0)
Could not get extcon-dev /host1x/nvdisplay@15210000:typec0(0)
Could not get extcon-dev /host1x/nvdisplay@15220000:typec1(0)
tegra-i2c 31e0000.i2c: no acknowledge from address 0x69

5

Is this the dev kit, or a third party carrier board? The i2c could be hardware issues if this is the dev kit, but if this is a third party carrier board, then you have to use the board support package/device tree intended for that carrier board (i2c would be routed incorrectly without that).

Also, note that the serial console comes through the micro-B USB. The type-C is for flashing and other uses.

6

It is the dev kit and not a third party carrier board.

Attached is the log from resetting the device
log.txt (212 KB)

7

Something to point out from earlier boot:

e[1;55re[54;1H[0002.228] I> enabling 'vdd-hdmi-5v0' regulator
e[1;54re[54;1H
e[1;55re[54;1H[0002.234] I> regulator 'vdd-hdmi-5v0' already enabled
e[1;54re[54;1H
e[1;55re[54;1H[0002.234] E> tegrabl_display_init_regulator: hdmi cable is not connected
e[1;54re[54;1H
e[1;55re[54;1H[0002.235] E> tegrabl_display_get_pdata, failed to parse dtb settings
e[1;54re[54;1H
e[1;55re[54;1H[0002.241] E> invalid display type
e[1;54re[54;1H
e[1;55re[54;1H[0002.247] E> invalid display type
e[1;54re[54;1H
e[1;55re[54;1H[0002.248] E> cannot find any other nvdisp nodes
e[1;54re[54;1H
e[1;55re[54;1H[0002.248] E> no valid display unit config found in dtb
e[1;54re[54;1H
e[1;55re[54;1H[0002.253] W> display init failed

Are you operating without HDMI (and can you give details on anything which may be special or unusual about the monitor)? This isn’t in itself an issue, but if you have a monitor connected and still see this, then the i2c query is failing and may be a side effect of hardware failure (normally this is just a device tree or monitor issue, but for your case perhaps it is more).

Later, as the kernel starts, this is what I see for the kernel command line:

e[1;55re[54;1H[    0.000000] Linux version 4.9.140-tegra (buildbrain@mobile-u64-2988) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMPe[54;204H e[54;204HPe[54;204HRe[54;204HEe[54;204HEe[54;204HMe[54;204HPe[54;204HTe[54;204H e[54;204HWe[54;204Hee[54;204Hde[54;204H e[54;204HMe[54;204Hae[54;204Hre[54;204H e[54;204H1e[54;204H3e[54;204H e[54;204H0e[54;204H0e[54;204H:e[54;204H3e[54;204H0e[54;204H:e[54;204H1e[54;204H1e[54;204H e[54;204HPe[54;204HDe[54;204HTe[54;204H e[54;204H2e[54;204H0e[54;204H1e[54;204H9e[54;204H

There are a lot of characters there which may or may not be something the kernel understands. After the unit boots, what do you see from:

cat /proc/cmdline

(if those are just ansi escape sequences, then it is likely the terminal itself putting those characters out)

The odd characters could simply be from applications reading the logs not understanding the character set/encoding, but it is worth examining.

Later on I see more i2c errors, not necessarily associated with the display (but perhaps).

For the Gemalto Key, did you have to install any drivers? User space software? i2c and USB are unrelated, except perhaps if the USB is talking to a custom i2c device.

On the serial console, with just a mouse or keyboard installed, what do you see from “lsusb” and “lsusb -t”?

8

I’m sorry, I accidentally sent the logs of a working Xavier (got the two mixed up). I’ve attached the new logs now. This time the HDMI is plugged into a monitor

I’m not sure I can actually run

cat /proc/cmdline

As I don’t get any response from the device using minicom. Maybe I need to set up the serial port in a specific way to do this? However, I haven’t got past setting up Linux after I reset the Xavier so maybe this is why?

To get the logs into the txt file I ran

minicom -D /dev/ttyUSB3 -C log.txt

Maybe this caused the strange characters?

With regards to the Gemalto key, we have other Xaviers where no setup was required, no drivers etc. So I think it is specifically this device that is having problems as we have had working software running on the others.

Could just be a hardware problem, but not sure what would cause all the USB ports to stop working if that is the case.

Thanks for all the help
log.txt (90.2 KB)

9

Looks like the kernel command line is ok, the earlier characters were indeed just ANSI escape sequences.

Do you have a PCIe expansion card installed? If so, please describe it.

The log says the system had loaded Linux, and was proceeding to fully boot, then had a thermal config failure. Other details make me think that since this is a standard development kit there was some sort of device tree update. Has the device tree ever been modified? I am not certain about this, but see this log excerpt:

[0000.313] W> MB1_PLATFORM_CONFIG: Rail ID 9 not found in pmic rail config table.
[0000.320] E> FAILED: Thermal config
[0000.323] W> DEVICE_PROD: device prod is not initialized.
[0000.328] W> DEVICE_PROD: device prod is not initialized.
[0000.337] W> MB1_PLATFORM_CONFIG: <b>Rail ID 7</b> not found in pmic rail config table.

Thermal config could cause a shutdown. An incorrect device tree could cause thermal config failure. Maybe this isn’t even related to the current problem, don’t know.

If the wrong power rail fails, then what you described could happen. I don’t know how much power the Gemalto Key consumes, though probably not a lot. I have no idea if “Rail ID 7” provides power to USB, but since this is where the serial console log ends, and since power does not seem to come up, odds are high that this rail is the problem.

Would someone from NVIDIA be able to say if “Rail ID 7” missing from the pmic rail config table will prevent boot? I do not personally have the details of the specific rail.

10
  1. Are you using a pure image from sdkmanager w/o modifying anything?
  2. Have you tried to reflash the device?
  3. Are there any other devices connected on your devkit espcially pcie/m.2?
11

  1. Yes, as far as I understand it’s a pure image from SDKManager - JetPack 4.2.0

  2. Yes, I had previously flashed it and USB was working. It then stopped working but everything was still installed. I flashed it again to make sure there was no problem with the image but now can’t go through the setup to install the rest of the software after the flash as none of the USB ports work with a keyboard. It is however sending data over the Micro-USB port as I can see the boot up logs through Minicom on ttyUSB3.

  3. No PCIE/M.2. The only two things that are changed from it being a standard devkit is a jumper that ties pins 5 and 6 together on J508 and a Kingston mSATA SSD. I’ve tried removing the jumper but has made no difference

12

Can you try booting without the mSATA? Was the mSATA connected during flash? Even if boot still fails it would be of interest to see how dmesg changes if the mSATA is removed (assuming it was connected in earlier dmesg).

13

Currently away over Christmas so don’t have physical access to the device. I will try when I get back.

It was originally connected when flashing and didn’t cause a problem and hasn’t been a problem on other devices I’ve flashed.

I’m not sure if there have been any patches in the latest versions of JetPack for something relating to this (in JetPack 4.2.2), but have used 4.2.0 for other Xavier devices so assumed it would work as previously. Could just be a hardware problem, but wanted to rule out software issues before sending it back.

14

Does the issue exist if the device is flashed with Jetpack 4.3 and mSata removed while flashing and the jumper is set as per the defaults while flashing? Did you try using USB hub? Powered USB hub? Non-Powered USB hub?

15

JetPack 4.3 wasn’t available when I was trying this so unfortunately can’t tell you if that’s the problem at the moment. However, have tried to flash without the jumper with JetPack 4.2.0 and it made no difference.

Have also tried both powered and non-powered USB hub. The problem with the USB not working is not power related as far as I can tell, as it will power a device (such as a USB Hub with an LED) but won’t interact with it correctly (e.g. A keyboard connected to the USB hub will not allow any input). I initially thought the Gemalto Key was losing power as the LED turned on at boot for a second and then turned off, but realised the Gemalto Key’s LED only lights up when in use, so the USB still had power even though the key wasn’t lit up.

16

A serial console log is probably required for further ideas. Earlier it seemed you were having issues with this, but as you connect the micro-B USB to the Xavier and the type-A end of the cable to the linux host PC, there should be a log message (monitor “dmesg --follow”, and see what changes as the cable connects). The first device is the one the serial console should connect to.