FTDI not recognizing Arduino Uno

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi everyone,
I’m trying to connect my Arduino to my TX2 for serial communication. The device is being recognized just fine, but the FTDI driver fails to create the proper link in /dev/tty*. Here’s what I’m seeing:

$ dmesg --follow
[ 1654.817378] usb 1-1.3: new full-speed USB device number 7 using xhci-tegra
[ 1654.918594] usb 1-1.3: New USB device found, idVendor=2341, idProduct=0043
[ 1654.925572] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[ 1654.933359] usb 1-1.3: Manufacturer: Arduino (www.arduino.cc)
[ 1654.939200] usb 1-1.3: SerialNumber: 952373238343515182A1
[ 1654.945371] usb 1-1.3: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 007: ID 2341:0043 Arduino SA Uno R3 (CDC ACM)
Bus 001 Device 004: ID 154b:005b PNY Flash Drive
Bus 001 Device 003: ID 046d:0825 Logitech, Inc. Webcam C270
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ sudo lsusb -d 2341:0043 -vvv

Bus 001 Device 007: ID 2341:0043 Arduino SA Uno R3 (CDC ACM)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x2341 Arduino SA
  idProduct          0x0043 Uno R3 (CDC ACM)
  bcdDevice            0.01
  iManufacturer           1 Arduino (www.arduino.cc)
  iProduct                2 (error)
  iSerial               220 952373238343515182A1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           62
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               10.01
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

dmesg | grep FTDI
[    2.650037] usbserial: USB Serial support registered for FTDI USB Serial Device

Based on what I’ve seen online, I believe that the output of the last command should look more like

[10170.987708] USB Serial support registered for FTDI USB Serial Device
[10170.987915] ftdi_sio 9-1:1.0: FTDI USB Serial Device converter detected
[10170.991172] usb 9-1: FTDI USB Serial Device converter now attached to ttyUSB0
[10170.991219] ftdi_sio: v1.6.0:USB FTDI Serial Converters Drive

What should I do? I’d like to have an entry like “dev/ttyACM0”, but that isn’t getting created.
Thanks in advance for the help.

2

FTDI has many USB chips, but their serial UART is very common and well supported. The gist is that first USB queries the device, and the device describes itself, and then a driver has to take ownership. From the USB side your device is functioning since it is detected and it describes itself. USB can contain more than one function though…essentially being multiple hardware devices sharing a single cable. A USB serial port usually takes a name such as “/dev/ttyUSB0” (or some other number prefixed with “ttyUSB” if there are multiple serial UARTs), and anything different is a result of udev renaming it.

udev has to have rules to recognize a device, else it won’t rename it. Sometimes those rules are generic, e.g., there tends to be a renaming of most ethernet devices these days, but there are still many devices (such as yours) which would need additional changes to get this new name even if a driver is present. The question is whether a driver has taken ownership of the various functions, and if this has occurred, if udev has made any naming changes. Sometimes the reverse is required, perhaps a rename has to occur before the driver knows it will work with the device. I don’t know what your particular device requirements are.

From your log messages it is obvious the FTDI device is 100% correct since it produces ttyUSB0. Assuming that this serial UART is to be used as ttyACM0 I would guess that you need a udev rule (normally part of a package install for the hardware) to perform that rename. Alternatively, perhaps ttyUSB0 is a separate function on the cable and that ttyACM0 requires its own separate driver (a case of independent hardware functions sharing a cable)…I don’t know. Some research on the Arduino Uno is probably needed to know what packages are available and/or required…your desktop system probably has those packages by default if ttyACM0 is produced there.

3

linuxdev,

Thanks for your help. That last code snippet was an example of what it’s expected to look like. Unfortunately, my TX2 is actually producing the second-to-last output.

Here’s something else that I’ve figured out: the ftdi_sio driver isn’t loading. I’ve tried

$ sudo modprobe ftdi_sio
$ lsmod | grep ftdi_sio

But both commands return absolutely nothing.

4

There are different types of serial to USB converter used by the Arduino manufacturers. Some use FTDI, others use CP210x. You can see from your post:

Uno R3 (CDC ACM)

This indicates that the device will report as something like /dev/ttyACM* where * is an integer.

The easiest way to check this is to plug the Arduino into a desktop or laptop and see how it reports.

The stock Jetson TX2 kernel does not have a built in CDC ACM module, you will have to build one yourself if you want to use the Arduino with it.

5

Kangalow,

Thanks for your advice, it was just what I needed! In case anyone is wondering, I had to rebuild the kernel with the CDC ACM included. To accomplish this, I had to flash the TX2 using Jetpack, then use some scripts provided by jetsonhacks.com. After doing all that, the Arduino was recognized.

6

All the Arduino Uno boards use a second Atmel chip for the USB<->Serial interface.
The first Unos used the Mega8u2, but the later ones upgraded to Mega8u16.
(Yes, that means they use a second chip that’s at least as powerful as the “main” Atmega microcontroller, just to drive the USB/Serial port.)

That being said, the solution is correct: You need to re-configure the kernel to include the CDC ACM USB device class.
Might as well turn on USB UVC while you’re at it, for USB webcams.
And, if you’re still on 27.1, you want to also turn on the CAN support.

I understand that NVIDIA wants to save space on the image, but there’s plenty of free space, and building in the most common USB drivers will save more trouble than it costs in kilobytes, so I think they should do this by default.