Xavier NX not recognizing certain ACM USB device

Thanks, I can test this tomorrow. However, on the working TX2, this setting is enabled.

I just realized I don’t know how to change this setting. Any resources you could point me to?

CONFIG_USB_UAS is a kernel feature/symbol. A symbol or feature is simply configured in the kernel source, and then compiled as a module or integrated to the kernel. Not all features/symbols can be in module format, but many can. Modules are easier to work with if they are supported. However, first check if the feature/symbol is already present:
zcat /proc/config.gz | egrep 'CONFIG_USB_UAS'
("=m" is present in the form of a module, “=y” is present in the form of integration into the kernel Image)

Typically, if the feature is not needed during boot, then this could be added as a kernel module (a simple file copy). If needed during boot, then typically you would either add the module to the initrd as well as the module directory, or else integrate this directly into the kernel (compiling a new kernel instead of a kernel module). Either way you would start with the existing kernel’s configuration, conveniently supplied via “/proc/config.gz”. Does your system already have CONFIG_USB_UAS? No need to build anything if it is there, although if boot is involved, then you might need to make the feature available earlier in the boot chain (Linux is actually the last part of the boot chain).

In the case of talking to a USB device after boot there is no need for the feature to be present early on.

My system already has CONFIG_USB_UAS.

$ zcat /proc/config.gz | egrep 'USB_UAS'
CONFIG_USB_UAS=y

How do I unset it or remove it from this configuration? If I understand correctly, @DaneLLL is suggesting to try disabling it.

Hi,
Please refer to kernel customization in development guide.
You can remove it from tegra_defconfig and rebuild kernel.

Sorry, just saw the above. lsusb uses a manufacturer ID and device ID. The 0001 is a manufacturer ID, the 0002 is a product ID. This is from the lsusb. Your device reported more than one component, and one of them was ID combination 0001:0002 (which implies it is a default which was never set up). Command line to lsusb sets this up in that format, e.g., “lsusb -d 0001:0002” queries only manufacturer 0001 devices, device type 0002

Yes, the above says the feature is integrated into your kernel, not as a loadable module, and @DaneLLL is saying to build a new kernel where everything is the same other than disabling that symbol, CONFIG_USB_UAS.

The documentation provides instructions for cross compiling a kernel on an Ubuntu host PC. One of the first things you’d do is set up your temporary build location. After that you’d set up the kernel configuration, followed by building the kernel. The choices for starting configuration will either be “make tegra_defconfig” (see the build docs, other options are involved to name output locations), or copying in the running system’s “/proc/config.gz” (after gunzip and rename to “.config”). Then editing that parameter, and setting CONFIG_LOCALVERSION="-tegra" (this can be a direct edit to your “.config”).

When you build the configured kernel there will be an “Image” file to either flash or copy in place, depending on circumstances. You can always ask for more information if the docs don’t provide enough information.

FYI, what I mentioned about editing CONFIG_LOCALVERSION in the “.config” file is so that the output of “uname -r” remains the same on both old and new kernels. “uname -r” is part of how the kernel finds modules. If this is the same, then generally you don’t need to install or worry about modules, and only worry about the Image file. If you change uname -r, then you have to also build and install all of the modules.

Whenever you are in an editor, and you find a feature (which is why I prefer “nconfig” which supports searching for symbols), then the “n” key will disable the feature (the “y” key sets “=y”, the “m” key sets “=m”, and you want “=n”).

FYI, before you start building a kernel I recommend installing the right ncurses package which is needed for most of the configuration editors:
sudo apt-get install libncurses5-dev

BTW, you can disable UAS for a specific device on the kernel command line as follows:

usb_storage.quirks=0x152d:0x0562:u

Substitute 152d with the vendorId and 0562 with the productId of the device you want to remove UAS from.

No need to recompile kernel.

I have modified the kernel as @DaneLLL suggested and I am still having the same issue.

$ zcat /proc/config.gz | grep USB_UAS
# CONFIG_USB_UAS is not set

Still the same output:

sudo journalctl -f
Jun 16 16:00:08 nx kernel: usb 1-2-port1: Cannot enable. Maybe the USB cable is bad?
Jun 16 16:00:08 nx kernel: usb 1-2-port1: Cannot enable. Maybe the USB cable is bad?
Jun 16 16:00:08 nx kernel: usb 1-2-port1: attempt power cycle
Jun 16 16:00:11 nx kernel: usb 1-2-port1: Cannot enable. Maybe the USB cable is bad?
Jun 16 16:00:12 nx kernel: usb 1-2-port1: Cannot enable. Maybe the USB cable is bad?
Jun 16 16:00:12 nx kernel: usb 1-2-port1: unable to enumerate USB device

Nothing shows up in lsusb. Not sure where to go from here. It’s not even seeing the device or vendor id, so udev rules don’t seem likely to help.

Are there other kernel modules that may be interfering with it?

When you say “nothing shows up in lsusb” do you mean the device isn’t showing up but other things are or literally “nothing”? If the device isn’t even showing up, then kernel modules, UAS, ACM, etc have no bearing. You’re never getting that far.

If you have a USB powered hub, try connecting the device to the hub then the hub to the NX.

1 Like

I meant the device doesn’t show up in lsusb. Every other USB device is there as I would expect. You’re right, it didn’t seem to be getting that far.

I actually just tried a USB hub earlier today and it finally works.

Unfortunately our system is pretty space limited so I would hope to not have to use a hub long term. What does this solution indicate and is there anything I can do to make it work without a hub?

Hi,
Please share more information.

In this working case, do you use r32.4.2 or other version?
Also does it work on TX2 + default carrier board?

I’m wondering if you just have a defective board that’s either not supplying enough power or if maybe the USB phy is bad. It could also be a “marginal” cable. Can you tell if the M300 is getting power? Any indicators that show up when connected to the TX2 or hub that don’t when it’s connected directly to the NX? You’ve probably already tried this but how about a cable swap? Finally, how are you powering the NX?

The Auvidea carrier board was running on the Dec 2019 image from Auvidea. Unfortunately I don’t have access to the setup anymore to check the L4T version. I never tested it on the TX2 with a dev board, but it did work using the DJI Manifold 2 with a TX2. That was running DJI’s image.

Thanks for the suggestions, unfortunately I don’t have access to the setup anymore, but I can offer what I tried.

The USB hub I used to get it to successfully run was unpowered. It was some generic Amazon USB hub that can optionally be powered, but I didn’t have any power supplied.

The M300 is powered by its own batteries. The Nvidia board actually connects to the M300 through the USB 2.0 port on the Onboard Computer adapter board. All these elements are relatively new, having been released within the past few months.

Finally, yes I’ve tried different cables. And I’ve tested the NX powered by the 19 V supply that comes with it, and with a 12 V supply coming from the M300.

DJI’s documentation leaves a lot to be desired. :) So their provided cable is a A to A cable then you have to use an adapter? I can’t tell. It’s definitely something at the lowest level though since it sounds like the hub is re-generating/shaping/timing the USB signals. It may be that both the NX and the DJI interface adapter are just a tiny bit out of spec such that when connected to devices that ARE in spec it’s not enough to cause a problem but when connected to another device that’s also a tiny bit out, it adds up to enough out that they can’t even negotiate. I’d consider a RMA of the NX if possible.

1 Like

I appreciate the help. You’re correct, it’s an A to A cable to an adapter box. I wonder if there’s some issue with the NX/M300 host to device relationship. Something like incorrectly treating the M300 as a host when it should be treated as a device (not sure of the terminology here). But when it runs through a USB hub, it’s forced to treat it as a device.

I have been trying to connect the Xavier NX to the DJI M300 drone (via an X-Port) but I have had no luck so far. Oddly enough, it worked fine with the TX2 as has been mentioned in this thread.

@jeffav2 Did you get further with this problem?

The only way I was able to get it to work is by using a simple USB hub between the Xavier NX and the M300 adapter box. I haven’t touched it since then.

I’m not familiar with an X-Port. How are you connecting everything?

I found a solution to my problem:

However, to answer your question, the X-Port is connected to the M300 via the onboard gimbal. The other end of the X-Port connects to a Payload SDK board.

The Payload SDK has two connections to the Xavier NX. The first connection is ethernet <-> ethernet. The second connection is UART (TX, RX, GND) <-> UART [J12] (Pins 10, 8 and 9 respectively.)