Installing cp210x usb to uart driver on Jetson Nano

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

I am trying to connect rplidar A1 to Jetson Nano but Jetson cannot recognize it as usb device. I tried to install cp210x as explained in [url]https://www.jetsonhacks.com/2018/02/09/install-usb-serial-converter-kernel-modules-l4t-28-1/[/url] but it does not work - probably because the Module version (4.4.38-tegra) does not match the Kernel version (4.9.140-tegra)

What also confuses me is that I am on L4T R32.2 and the instructions at the link above say that starting with L4T 28.2 version CP210x driver will be a part of the stock kernel so there would be no need to use the jetsonhack solution above.

I am new to Jetsons and really appreciate if you could point me in the right direction.

P.S. I am on the most recent JetPack 4.2.1. with L4T R32.2

2

Any suggestions?

3

What do you see from:

zcat /proc/config.gz | grep CP210

If this says “=y” or “=m”, then you have support for that particular UART. The “=m” could still fail if the module is not being loaded.

What do you see from “uname -r”?

If this is “=m”, then your thought that the kernel version may be the issue is probably correct. Modules are searched for at “/lib/modules/$(uname -r)/”. If a different kernel is loaded, then the modules must also be installed for the new kernel. A module from a different “uname -r” may or may not work (depending on several issues), and it is always recommended that if you build a new kernel which has a new “uname -r” that you rebuild all modules from scratch. A module from 4.4.38-tegra is very likely to fail when used with 4.9.140-tegra.

What do you see from:

find /lib/modules/$(uname -r) -name '*cp210*'
4

sell this: /lib/modules/5.0.0-25-generic/kernel/drivers/usb/serial/cp210x.ko

5

The Ubuntu 18.04 host recognizes the cp210x chip and is connected with: $ dmesg --follow, and I set minicom to ‘ttyUSB0’, but when I run $ sudo minicom it comes out:
Welcome to minicom 2.7.1

OPTIONS: I18n
Compiled on Aug 13 2017, 15:25:34.
Port / dev / ttyUSB0, 10:37:07

Press CTRL-A Z for help on spec keys

and below it comes out:

115200 8N1 | NOR | Minicom 2.7.1 | VT102 | not connected | ttyUSB0

6

To USB to TTL (chip CP2102) I have connected Tx, Rx and ground with the Jetson Nano

7

Realize that minicom came from a day when people used telephone modems most of the time. Those modems were not only serial UARTs, they also had “AT” command sets…short commands which configured the modem itself and not just the UART. “Not connected” could be referring to a telephone PPP or SLIP connection and not to the UART. If modem init strings are being sent there is no telling what the result would be.

I’ll recommend testing first with gtkterm since it is purely a serial console:

sudo apt-get install gtkterm

If you use this on a system with ttyUSB0 as the port, and if the port is set to 115200 8N1:

gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0

Wiring:

  • RX of one to TX of the other.
  • TX of one to RX of the other.
  • Grounds connected.
  • Optionally, if hardware flow control is used (not used in serial console, but perhaps used for your app):
    • CTS of one to RTS of other.
    • RTS of one to CTS of other.

    • Note that if two ports are using different settings, then you will either get no output or output will be corrupt.

    If you wish to test a port you can use loopback to have the port talk to itself. The result would be the serial terminal seeing echo of what you type if it works, or nothing if it fails. Let’s say your system has ttyUSB0, and you use gtkterm as above to talk to ttyUSB0. If you wire TX to its own RX (and optionally CTS to its own RTS), then you have loopback. If this works you know the port is working at those settings.

8

The RPLidar does not use hardware flow control

Separately, the RPLidar just dumps a fast set of data points on the serial port and expects the host to read it.
You also need to turn off software flow control, because the data it spits out will include the “XON” and “XOFF” characters.

If you don’t have the right baud rate, you will see nothing, but if you connect it correctly, you should be able to read data from the serial port with something like:

sudo stty 115200 -ixon -ixoff < /dev/ttyUSB0
sudo dd if=/dev/ttyUSB0 bs=16 | xxd

You don’t need to use minicom or picocom for this.

9

hi . can you explain how to load the cp210x driver .

zcat /proc/config.gz | grep CP210

the above yielded me

CONFIG_USB_SERIAL_CP210X=m

but, i am not able to find the ttyUSB0 or any driver for the cp210x under usb-devices cmd . pls help on installing cp210x driver

10

[/quote]

hi . can you explain how to load the cp210x driver .

zcat /proc/config.gz | grep CP210

the above yielded me

CONFIG_USB_SERIAL_CP210X=m

but, i am not able to find the ttyUSB0 or any driver for the cp210x under usb-devices cmd . pls help on installing cp210x driver

[/quote]

after some research i found the way to install cp210x driver . thanks for your help . here are the steps to install for references

download the cp210x driver source for linux from here
https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

extract and cd into the folder

run make cmd
$make

copy the cp210x.ko file into the kernel driver

$sudo cp cp210x.ko /lib/modules/“$(uname -r)”/kernel/drivers/usb/serial/

reboot just to solidify all

Thanks

11

Some description of how drivers work for this may help.

A driver for a regular serial UART over USB bridge would normally create a file name of the format “/dev/ttyUSB#”, where number is anything from 0 and up. However, the udev naming system may detect certain manufacturer’s devices or chipsets, and choose to rename the UART. The end of the communications, where the USB is plugged in, will name any device as the device connects.

So for example, if you monitor “dmesg --follow” on the host PC, and then plug in the serial UART, you may see a note about “/dev/ttyUSB0” (if it is the first such device). For a different chipset, you may also see an alternative name when udev renames the device. What do you see as you plug in the USB end?

The driver itself only works if USB tells the driver there is a device it might be interested in, and then the driver takes ownership. This too would be noted in the “dmesg --follow” during plug in. For any case where the driver is already present (such as seeing it as “m” or “y” in CONFIG_USB_SERIAL_CP210X) there is no need for you to specifically activate this (the hot plug layer does this).

The kernel has the code for this driver natively available to it. There is no need to build the driver with outside source code, the original kernel source should have this. If the CONFIG_USB_SERIAL_CP210X says “=m” or “=y”, then this was already done, and any additional kernel module file may just confuse or overwrite the correct module.

The method listed above from the silabs.com URL will work, but it is going through a lot of effort which probably isn’t needed.

12

modprobe cp210x does seem to load the driver but doesn’t appear to create /dev/ttyUSB0

mknod seems to create the device but not reflected by usb-devices

 sudo mknod /dev/ttyUSB0 c 188 0
nvidia@nvidia-desktop:~$ ls /dev/ttyUSB0
/dev/ttyUSB0

 usb-devices

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 4
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev=04.09
S:  Manufacturer=Linux 4.9.140-g4df3950 xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=3610000.xhci
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  8 Spd=480 MxCh= 4
D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=2109 ProdID=2811 Rev=90.40
S:  Manufacturer=VIA Labs, Inc.         
S:  Product=USB2.0 Hub             
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub

T:  Bus=01 Lev=02 Prnt=08 Port=00 Cnt=01 Dev#=  9 Spd=1.5 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04f2 ProdID=0833 Rev=02.30
S:  Manufacturer=CHICONY
S:  Product=USB Keyboard
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

T:  Bus=01 Lev=02 Prnt=08 Port=01 Cnt=02 Dev#= 10 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=1c4f ProdID=0034 Rev=01.10
S:  Manufacturer=SIGMACHIP
S:  Product=Usb Mouse
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 4
D:  Ver= 3.10 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev=04.09
S:  Manufacturer=Linux 4.9.140-g4df3950 xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=3610000.xhci
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub

trying to get rpilidar via usb hub or without usb hub [ powered]; any insights?

13

This should probably be avoided:

For the most part the drivers will create the device special file as the driver loads (when you have udev, and every modern distribution does, even old versions of modern distros). Long ago all device special files were created this way, but the registry of major and minor devices was getting to be huge, and so they went to dynamic generation. The file itself doesn’t cause a driver to associate unless this is what the file would have used anyway. Failure to create a “/dev” file upon driver load indicates something else is going wrong.

Tip: A few devices in “/dev” exist in the actual eMMC filesystem during a clone…these are most likely ones used in an initrd ramdisk when udev does not run. Possibly some of these are used by the running kernel prior to udev running.

If you run “dmesg --follow”, then insert the cable, what do you see? What do you see from “lsusb”? It is possible USB is working as expected, but the driver does not know it is used with that hardware. It could be as trivial as the UART having a different device ID when used in someone else’s hardware (it is common for a standard serial UART to get a new manufacturer and device ID for that manufacturer’s product…then the generic driver still works, but the driver does not know this unless udev tells it so).

14

@linuxdev
should the device /dev/ttyUSB0 emerge on execution of
modprobe cp210x given there is no usb devices attached physically?
if it appears upon loading of the modprobe normally, there should be some issue as it won’t create neither on AGX, nor on nano nx/ nano devkit, as per my test outcomes.

15

The USB side is the side where the device special file will show up upon driver load (assuming USB serial UART and not direct wired UART). The driver should not load if no device is present (you can force this, but it doesn’t mean much). Loading a driver (indicating hardware found) should generate a device special file (not necessarily a name you expect since udev might rename this).

Insmod of a driver capable of handling a serial UART using a custom manufacturer/device ID would be the same as not finding hardware, unless udev tells the driver the two are compatible. No matter how a driver is forced to load, if the driver does not know it can pair with that hardware (presumably via IDs for USB), then the device special file will not show up.

In the case of a serial UART directly wired into the unit, then the device tree would provide information to tell the driver what is there and where to find it…essentially something a USB side would inform the driver about. udev can still be involved in renaming for integrated devices wired to the memory controller.

Usually an association of which driver handles the device will be found in dmesg. In the case of USB insert, then that information appears upon insert. If that messages stops with manufacturer and device ID, and does not mention device special file or driver, then likely either the driver is missing or the driver does not know it is compatible.

One reason I keep looking for the plain “lsusb” output, without anything else, is that I want to see the list of IDs. Finding that information via “ls /dev/ttyUSB*” somewhat depends on successful driver load and pairing, but I am interested in the raw USB broadcast, not the result of the broadcast.

Assuming this is the Jetson itself (but it doesn’t really matter), run “dmesg --follow” on one terminal, and run “watch -n 1 lsusb” on another terminal, and see what happens when you plug in the connector. I am assuming you are interested in the side with the USB insert. This provides the details to know what issues might cause a driver to not associate (e.g., manufacturer customization).

For a driver load to create a device special file with any meaning it has to have a specific piece of hardware to associate with (presumably USB, but possibly integrated to a memory controller and set up with device tree). mknod creates a file, but it has no meaning since the driver is not loaded in combination with being initialized for a specific piece of hardware.