ttyACM0 does not work with the micro AB USB port

Hello!

I want to connect Arduino with Usb-to-Serial chip CH340 to my Jetson TX2 with Jetpack 3.2.1. I built and installed the cdc-acm and ch341 drivers, as described on the Jetsonhacks website. On the USB 3.0 connector everything worked perfectly. I can read data from /dev/ttyACM0 using minicom. My “dmesg --follow” command outputs

[ 612.012794] usb 1-2: new full-speed USB device number 2 using xhci-tegra
[ 612.156241] usb 1-2: feature bit otg_vbus_off set
[ 612.161190] usb 1-2: New USB device found, idVendor=2341, idProduct=0042
[ 612.168359] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[ 612.176408] usb 1-2: Manufacturer: Arduino (www.arduino.cc)
[ 612.182496] usb 1-2: SerialNumber: 55732323930351717172
[ 612.190562] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[ 612.201587] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 612.210616] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[ 613.436887] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[ 613.445148] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request

But when I connect to micro AB USB connector, I do not see any data in minicom and minicom hangs for a while. My “dmesg --follow” command outputs

[ 1568.550504] usb 1-1: new full-speed USB device number 3 using xhci-tegra
[ 1568.691755] usb 1-1: feature bit otg_vbus_off set
[ 1568.696743] usb 1-1: New USB device found, idVendor=2341, idProduct=0042
[ 1568.704384] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[ 1568.712216] usb 1-1: Manufacturer: Arduino (www.arduino.cc)
[ 1568.718161] usb 1-1: SerialNumber: 55732323930351717172
[ 1568.726679] usb 1-1: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[ 1568.736289] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 1568.744509] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[ 1569.973909] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[ 1569.981115] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request
[ 1615.970286] cdc_acm 1-1:1.0: failed to set dtr/rts

I checked my micro-USB cable with other usb-to-serial converters. The cable is OK. I can read the data through micro AB USB connector from PL2303 chip (as /dev/ttyUSB0). My “dmesg --follow” command outputs

[ 2095.099115] usb 1-1: new full-speed USB device number 4 using xhci-tegra
[ 2095.233978] usb 1-1: New USB device found, idVendor=067b, idProduct=2303
[ 2095.240875] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2095.248192] usb 1-1: Product: USB-Serial Controller
[ 2095.253233] usb 1-1: Manufacturer: Prolific Technology Inc.
[ 2095.260570] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 2095.269553] pl2303 1-1:1.0: pl2303 converter detected
[ 2095.277607] usb 1-1: pl2303 converter now attached to ttyUSB0
[ 2096.526573] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[ 2096.533878] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request

I can read the data through micro AB USB connector from CH341 chip (as /dev/ttyUSB0). My “dmesg --follow” command outputs

[ 3526.925947] usb 1-1: new full-speed USB device number 5 using xhci-tegra
[ 3527.065175] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523
[ 3527.072148] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 3527.086268] usb 1-1: Product: USB2.0-Serial
[ 3527.094279] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 3528.259731] usbcore: registered new interface driver ch341
[ 3528.265629] usbserial: USB Serial support registered for ch341-uart
[ 3528.272358] ch341 1-1:1.0: ch341-uart converter detected
[ 3528.281125] usb 1-1: ch341-uart converter now attached to ttyUSB0
[ 3528.353139] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[ 3528.360902] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request

Help me please configure the micro AB USB port connection with my Arduino.

Sergey.

For clarification, would you give details on what is connected where? Is it correct that your USB cable is a serial USB UART cable which uses the ACM chip? Or is this integrated into the Arduino? I’m guessing that it is a separate cable since you said minicom works with it. Are any adapters used?

About the UART end of the cable…is this a 6-wire cable, or a 3-wire cable? Or does it have an integrated connector with 6 wires?

FYI, “cts/rts” wires are not always mandatory (6-wire setup), but you can set to software flow control (3-wire setup) and it will work. The caveat here is that other settings must still be correct, e.g., speed, parity, and stop bits. What settings does the Arduino use? What settings do you have control over at the Arduino itself? If speed goes over 115200 you’ll possibly need two stop bits (not necessarily though since you have an external ACM UART).

Note that having USB work allows the system to detect the need for the ACM driver, and this seems to have occurred. Whatever software wants to talk through the ACM UART might still need to be told which “/dev” file it belongs to…some assume a “/dev/ttyACM”, others might assume a “/dev/ttyUSB”, and yet others might assume a “/dev/ttyS”.

I connect the Jetson TX2 and the Arduino Mega 2560.
Arduino sends in Jetson 2 times a second a short message at 9600 baud.

Arduino has on board usb-to-serial converter, which is made on a chip CH340, and USB-B connector.
Jetson has a USB 3.0 Micro Type B connector and a USB 2.0 Micro Type AB connector.
I connect Arduino and Jetson with a USB cable (and microUSB-to-USB adapter).
If I connect Arduino’s USB-B connector and Jetsons’s USB 3.0 Micro Type B connector, everything is fine.
If I connect Arduino’s USB-B connector and Jetsons’s USB 2.0 Micro Type AB connector, then failed to set DTR/RTS.
If I connect Jetsons’s USB 2.0 Micro Type AB connector and a USB connector of another usb-to-serial converter, then everything is also fine.

Sorry for my English.

Is it the same if you swap AB connectors ? One issue may be if both are OTG, the cable plugs would determine which is host and which is device.

How can this be diagnosed?

Probably lsusb would only work on host side.

Just swap both ends of the cable…plug the connector that was in Jetson into Arduino and vice-versa and try again.

I can confirm that if “lsusb” shows the UART, then it is the right kind of connector. This would imply the port is acting as host and not as device (the UART is a device which a host can use).

FYI, micro-B (when the Jetson is a device and not a host and the UART cable would not function correctly) has more rounded/beveled corners. For example see:
[url]https://files.cablewholesale.com/pwimages/10u2-031xx_05_th.jpg[/url]

The micro-A has a more square corner and is correct for use with the ttyACM serial UART. For example, this illustrates both the micro-A and micro-B:
[url]https://upload.wikimedia.org/wikipedia/commons/thumb/5/5d/Types-usb_th1.svg/271px-Types-usb_th1.svg.png[/url]

FYI, the development board has no micro-USB3, only the full-sized port is USB3, and this port is not capable of any mode other than host.

I don’t know the details of Arduino, but you can expect communications to fail unless both sides of the UART communications are set to the same settings, e.g., 9600 speed, 8-bits, 1-stop bit, no parity, software flow control (or both set to RTS/CTS…and even then only if the UART cable supports it). UARTs are not plug-n-play, they cannot auto configure.

I myself soldered the OTG USB cable, as shown in the bottom of the picture https://qph.ec.quoracdn.net/main-qimg-b388b2fddb25b44e77e868c4346ac25b.webp

When I connect my Arduino to Jetson’s USB 2.0 OTG connector my lsusb out is:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 2341:0042 Arduino SA Mega 2560 R3 (CDC ACM)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

In addition, the dmesg --follow command reports that the Jetson finds USB device:
[12907.812190] usb 1-1: new full-speed USB device number 4 using xhci-tegra
[12907.957300] usb 1-1: feature bit otg_vbus_off set
[12907.962424] usb 1-1: New USB device found, idVendor=2341, idProduct=0042
[12907.969790] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=220
[12907.977676] usb 1-1: Manufacturer: Arduino (www.arduino.cc)
[12907.983510] usb 1-1: SerialNumber: 55732323930351717172
[12907.991501] usb 1-1: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[12908.001807] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[12908.011057] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[12909.239521] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[12909.246909] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request

But when I run command minicom -b 9600 -D /dev/ttyACM0, I get an error:
[13341.797154] cdc_acm 1-1:1.0: failed to set dtr/rts

When I connect my Arduino to Jetson’s USB 3.0 connector minicom works fine.

I looked at the source codes of the drivers. It looks like the error occurs in the driver cdc_acm.
Can I somehow disable protocol CDC ACM and work with my Arduino like with a regular USB-serial device?

Not sure at all it will really help, but you may try to disconnect, then launch:

sudo systemctl stop ModemManager

and replug. If you see /dev/ttyUSB0, you may use it instead of /dev/ttyACM0.
You may also try to configure serial connection with SW or no flow control (this would be configured on both sides).

I am kill ModemManager. This action did not solve the problem.
My Arduino and so on the exceptions list /lib/udev/rules.d/77-mm-usb-device-blacklist.rules and not intercepted by the ModemManager.

I also turned off flow control.
$ minicom -s
±----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyACM0 |
| B - Lockfile Location : /var/lock |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 9600 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| |
| Change which setting? |
±----------------------------------------------------------------------+
Again I have an error
[17744.726220] cdc_acm 1-1:1.0: failed to set dtr/rts

Do you see /dev/ttyUSB0 ?

No. I see:
crw-rw---- 1 root dialout 166, 0 Jun 23 17:39 /dev/ttyACM0
crw–w---- 1 root tty 235, 0 Jun 23 11:45 /dev/ttyGS0
crw------- 1 nvidia tty 4, 64 Jun 23 11:45 /dev/ttyS0
crw-rw---- 1 root dialout 4, 65 Jun 23 11:45 /dev/ttyS1
crw-rw---- 1 root dialout 4, 66 Jun 23 11:45 /dev/ttyS2
crw-rw---- 1 root dialout 4, 67 Jun 23 11:45 /dev/ttyS3
crw-rw---- 1 root dialout 238, 1 Jun 23 11:45 /dev/ttyTHS1
crw-rw---- 1 root dialout 238, 2 Jun 23 11:45 /dev/ttyTHS2
crw-rw---- 1 root dialout 238, 3 Jun 23 11:45 /dev/ttyTHS3

PS ModemManager is not in the output of ps -A
nvidia@tegra-ubuntu:~$ ps -A | grep M*
nvidia@tegra-ubuntu:~$

FYI, even if you soldered cables incorrectly so far as ID pin goes, the existence of the device in “lsusb” implies the port is correctly in host mode for your ACM device. The USB side works.

The error you are showing is unrelated to USB should the USB show up…this is a serial UART error. I don’t know about the “dtr” abbreviation being shown, but for reference a serial port mandates a ground pin, a TX pin, and an RX pin (TX and RX are halves of a balanced pair). Hardware flow control optionally has a “Request to Send” (“RTS”) and “Clear to Send” (“CTS”) wire pair. Not all serial UARTs implement five wires, but all must implement three wires. In the case of standard serial UART cables with a 6-pin connector the extra wire is the +5V USB power bus in case of remote devices using this for power.

The use of or ignoring of CTS/RTS is optional. Software controls whether or not this is needed. Does the serial end of your cable (not the USB end) provide three wires or five wires (six wires implies five wires plus power)? Three wires means it isn’t possible to support CTS/RTS flow control.

If those requirements are met, then it is a case of both ends of the connection being told to use RTS/CTS flow control…if one end tries and the other does not, then perhaps one side is complaining and would succeed if both sides knew to use this.

ModemManager is an interesting idea since it could be trying to manage the device and using settings which don’t match the other half of the UART communications. I am not a fan of networking or other changes which occur on end user login to the GUI, but ModemManager uses DBus and thus is one of those. In theory it would mean there could be a Jetson-side configuration which changes depending on whether the user is logged in to the GUI or not…and depending on which user logs in. I doubt it would have configured for this case without manual intervention, but it could be useful to see if disabling/enabling has an effect on error messages.

How do I disable the CDC ACM driver and access the /dev/ttyUSB0?
I think the driver has an error

Can I sw change USB PID & VID so that the kernel takes my Arduino like this device on the same chip CH341?
Like here:
[ 3526.925947] usb 1-1: new full-speed USB device number 5 using xhci-tegra
[ 3527.065175] usb 1-1: New USB device found, idVendor=1a86, idProduct=7523
[ 3527.072148] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 3527.086268] usb 1-1: Product: USB2.0-Serial
[ 3527.094279] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 6
[ 3528.259731] usbcore: registered new interface driver ch341
[ 3528.265629] usbserial: USB Serial support registered for ch341-uart
[ 3528.272358] ch341 1-1:1.0: ch341-uart converter detected
[ 3528.281125] usb 1-1: ch341-uart converter now attached to ttyUSB0
[ 3528.353139] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work mailbox command 5
[ 3528.360902] xhci-tegra 3530000.xhci: tegra_xhci_mbox_work ignore firmware MBOX_CMD_DEC_SSPI_CLOCK request

I think that DTR stands for Data Terminal Ready.

Ahh! I am coming up with a case of Acronym Psychosis! Sorry, I had to invent something for too many acronyms which mean the same or similar things :P This would then mean DTR and CTS might be equivalents depending on hardware and software setup. I guess more would need to be known about what the Arduino wants or expects. In any case a pure UART won’t have more than the five pins, but old serial DB-9 or DB-25s are antiquated and might have more functions.

If you see /dev/ttyGS0, then probably you are on device side, not host.

@sergey.bilenko Can you post the output of

usb-devices

when ch341 device plugged in?

I’m trying to sort out the same issue… getting arduino nano clone with ch341 to work on jetpack 3.2.1

on my system shows

Driver=(none)

on my other (non-tegra) 16.04 systems shows

Driver=ch341

I’m using a orbitty carrier board and I’m vested in the image on my jetson now and don’t want to roast it just to cross-compile/re-image.

also… does following the jetson hack method of compiling on system cause any issue(s) with BSP, in the photos it looks like your on an auvedia board?.

I checked on my jetson… /dev/ttyGS0 is always there whether or not any usb devices are plugged in.