Install ttyACM Module on Xavier

I tried to install a ttyACM module to connect to a VESC motor controller. I followed this tutorial

https://www.jetsonhacks.com/2017/11/19/install-ttyacm-module-nvidia-jetson-tx-development-kits/

for the TX1/TX2.

As the tutorial states, the kernel version have to match. I’m using the 4.9 which doesn’t fit. I installed it anyway and of course it didn’t work. It is also stated that plenty of sites cover this topic. Maybe I google wrong, but I couldn’t find any helpful resources yet.

Is there currently a way to connect to ttyACM modules with the Xavier?

R32.1 should already have ACM. The URL you mention is from 2017 and a different Jetson. I don’t know which tty# your ACM would be, but if the right arguments are passed, then it should “just work”.

What command are you using? Is the command from the Xavier side? If you monitor “dmesg --follow”, and then plug in the USB, what do you see? What do you see from “ls /dev/ttyACM*” (I’m guessing at the name…some ACM setup renames the tty to this particular naming convention)?

dmesg --follow is showign this

[  197.738798] usb 1-4.1: new full-speed USB device number 7 using tegra-xusb
[  197.762847] usb 1-4.1: New USB device found, idVendor=0483, idProduct=5740
[  197.762856] usb 1-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  197.762861] usb 1-4.1: Product: ChibiOS/RT Virtual COM Port
[  197.762863] usb 1-4.1: Manufacturer: STMicroelectronics
[  197.762865] usb 1-4.1: SerialNumber: 301
[  198.919255] 80211> CFG80211_OpsScan ==>
[  199.985066] 80211> cfg80211_scan_done
[  199.985739] 80211> CFG80211_OpsSurveyGet ==>
[  199.985767] 80211> busy time = -261233387008 0
[  199.993979] 80211> CFG80211_OpsStaGet ==>
[  199.994116] 80211> CFG80211_OpsStaGet ==>
[  201.344332] 80211> No scan is running!
[  203.454134] 80211> No scan is running!
[  203.470845] 80211> CFG80211_OpsStaGet ==>
[  203.471039] 80211> CFG80211_OpsStaGet ==>
[  204.490200] 80211> No scan is running!
[  205.541837] 80211> No scan is running!
[  206.583799] 80211> No scan is running!

and with ls/dev/ttyACM* is not showing up

$ ls /dev/ttyACM*
ls: cannot access '/dev/ttyACM*': No such file or directory

Looks like the device is connected but not as ttyACM. However, it works on my Windows and Ubunut 18.04 machine. So the device should be okay. I am not using any commands. I’m trying to connect with the BLDC tool to the VESC. The problem is that the device doesn’t appear in the application. On my other machines the application (and the system) recognizes ttyACM0.

Either the chipset isn’t ACM, or the manufacturer customized this:

Manufacturer: STMicroelectronics

You’ll want to find the driver for STMicroelectronics (probably information on the STMicroelectronics board would mention). That driver would have to either be in source code format, or something in user space which updates udev to tell it that STMicroelectronics is the same as ACM.

In the USB chip industry several manufacturers sell more or less common and standardized chips for various tasks (such as serial UART) such that the manufacturer’s ID and product ID use that of the chip maker. This means that the actual end product manufacturer doesn’t need to bother with the expense of registering with usb.org, and doesn’t have to do anything special with drivers. In this case it appears the manufacturer chose to program their own IDs (perhaps they want proprietary control, or perhaps they have special functions they don’t want mixed up with other ACM devices). If you find out this is actually ACM and only the IDs were changed, then you might be able to do some manual intervention even if the manufacturer doesn’t provide arm64 support.

The bottom line is that the manufacturer purposely made this chip appear to not be ACM (assuming it really is ACM). The software doesn’t know if this is the case. Should another system recognize this chip, then it is likely there is a udev rule making that translation.

FYI, the USB registry shows:

Manufacturer ID 0483 STMicroelectronics
   Product ID 5740  Virtual COM Port

(which is not an ACM)

Well that’s interesting. On my Desktop Ubuntu 18.04 machine the VESC application shows it as ttyACM without installing anything.

As you said one might need to add an udev rule. In the tutorial which I have added in my initial post (see link) it is explained to download the repo https://github.com/jetsonhacks/installACMModule which contains a cdc-acm.ko file. I thought that would be necessary driver, isn’t it? There is in another script an udev rule which just gives the device a new name:

ACTION=="add", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", SYMLINK+="vesc"

This step was not necessary on my desktop machine too. However, after that the VESC application still doesn’t recognize it. It only shows tree ttySH* devices which all don’t connect. (Does three devices have always been showing up. No change).

I’ll check what the Desktop machine is actually detecting. Maybe there was an udev rule I haven’t noticed. Would it make sense to create my own udev rule to rename the device as ttyACM, so that the application might detect it? I doubt it.

udev will rename the original device name. The question is whether your PC is renaming from ttyACM to something else, or renaming from the custom name to the standard ttyACM. Which system is that udev line on? If this is present in the PC but missing on the Jetson, then you could probably add this to the Jetson and it would “just work” (be sure to reboot after changing). If this is present on the Jetson, but not the PC, then perhaps removing this from the Jetson would make it work (I’d bzip2 -9 the file instead of actually removing if it is to be removed).

This device is customized by the manufacturer. Presumably desktop Ubuntu has seen more use of this device and thus it is installed by default for desktop users. There are far fewer users of arm64 and it isn’t surprising the Jetson hasn’t been customized for this device. Basically you can blame the manufacturer for modifying a standard device in order to put their name on it.

I don’t know why MIT overwrote the driver in the first place. Maybe the driver wasn’t pre installed on their kernel version. However, after setting the drivers back to the default driver everything worked fine (on the desktop machine as well as on the Xavier)

You said just that in your first answer. I assumed the if the driver is already installed, it would not matter if gets overwritten. Thank you for your suggestion.