Serial USB RAQ - stronnag/mwptools GitHub Wiki

Serial USB Rarely Asked Questions

Unmaintained Article Please check the manual for more up-to-date information.

Fortunately Linux users rarely suffer from the USB serial (driver) issues that seem to inflict Windows users. Usually drivers are automatically detected, loaded and just work. Unless you happen to have the misfortune to own a Dell laptop ...

This article describes some steps you an take to identify such issues, and some clues as to how you might rectify the problem. See also the earlier wiki article, Serial-USB-checklist.

Basics

It is necessary that your user has read / write access to the USB serial device. This is achieved by adding the user to the group with access to the device, typically dialout or uucp.

  • Plug in the FC

  • Verify the device name

    $ dmesg | tail -n 10
[33533.645992] usb 1-4: new full-speed USB device number 7 using xhci_hcd
[33533.787415] usb 1-4: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[33533.787436] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[33533.787444] usb 1-4: Product: FURIOUS F35-LIGHTNING
[33533.787449] usb 1-4: Manufacturer: INAV
[33533.787454] usb 1-4: SerialNumber: 0x8000000
[33533.789507] cdc_acm 1-4:1.0: ttyACM0: USB ACM device

    Here the device will be /dev/ttyACM0

    $ ls -l /dev/ttyACM0
crw-rw---- 1 root uucp 166, 0 Jul 16 13:49 /dev/ttyACM0

  • Add the user to the group (here (Arch) it's uucp; Debian / Ubuntu would show dialout.

    $ sudo usermod -aG uucp $USER
# or
$ sudo usermod -aG dialout $USER

    where $USER is your user name.

  • Logout / login for the new group to be available.

    $ id
uid=1000(jrh) gid=1000(jrh) groups=1000(jrh),983(systemd-journal),986(uucp),998(wheel)

Now you can try the device with mwp or the inav configurator; both should recognise the device (/dev/ttyACMO) and offer it as the default device: we already have a good assurance that the device will work, because dmesg shows the correct Manufacturer and Product.

Note: If you're using systemd as your init system, then you can just use tag uaccess to avoid the user / group thing, udev rule:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", MODE="0660", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{ID_MM_CANDIDATE}="0"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0660", TAG+="uaccess"

The ENV statements prevent ModemManager from hijacking the connection.

When it doesn't work

So maybe you have a Dell laptop, one with the finger-print reader that doesn't work in Linux, but messes up other serial USB devices. I don't, this article is based on working with a couple of users who have Dell devices and mwp and / or the configurator didn't want to play.

First Example

Here's the dmesg output:

[Thu Jul  8 12:57:52 2021] usb 2-2: new full-speed USB device number 3 using xhci_hcd
[Thu Jul  8 12:57:53 2021] usb 2-2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[Thu Jul  8 12:57:53 2021] usb 2-2: New USB device strings: Mfr=1,Product=2, SerialNumber=3
[Thu Jul  8 12:57:53 2021] usb 2-2: Product: STM32 Virtual ComPort in FS Mode
[Thu Jul  8 12:57:53 2021] usb 2-2: Manufacturer: INAV
[Thu Jul  8 12:57:53 2021] usb 2-2: SerialNumber: 345337523237
[Thu Jul  8 12:57:53 2021] cdc_acm 2-2:1.0: ttyACM0: USB ACM device
[Thu Jul  8 12:57:53 2021] usbcore: registered new interface driver cdc_acm
[Thu Jul  8 12:57:53 2021] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

And a clue that we may have a problem:

  • The Product is reported as a Virtual ComPort in FS Mode. This is bad news.
  • Most Google searches either suggest that wrong firmware was flashed (it wasn't), or it's a Windows driver issue (obviously not here).

The user was unable to progress beyond this.

Second Example

The second user actually had a rather more extreme issue, but was experienced and resourceful enough to solve the problem with a bit of research and a few hints.

First of all we noticed (from dmesg) that that a 3rd party driver for the non-functional finger-print reader was loaded during boot:

[    2.250732] usb 1-10: new full-speed USB device number 5 using xhci_hcd
[    2.351349] system76_acpi: loading out-of-tree module taints kernel.
[    2.351366] system76_acpi: module verification failed: signature and/or required key missing - tainting kernel
[    2.353020] system76: Model does not utilize this driver
[    2.401376] usb 1-10: New USB device found, idVendor=27c6, idProduct=5385, bcdDevice= 1.00
[    2.401381] usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.401382] usb 1-10: Product: Goodix Fingerprint Device
[    2.401384] usb 1-10: Manufacturer: HTMicroelectronics
[    2.401384] usb 1-10: SerialNumber: HTK32
[    2.422149] usbcore: registered new interface driver system76-io

Later, when the FC was plugged in, the system obviously didn't like it:

[   66.939725] usb 1-9: New USB device found, idVendor=0483, idProduct=5740, bcd Device= 2.00
[   66.939728] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   66.939730] usb 1-9: Product: MatekF411SE
[   66.939732] usb 1-9: Manufacturer: INAV
[   66.939733] usb 1-9: SerialNumber: 0x8000000
[   66.940926] cdc_acm 1-9:1.0: ttyACM0: USB ACM device
[   67.042685] pci_bus 0000:05: Allocating resources
[   73.143040] cdc_acm 1-9:1.0: acm_port_activate - usb_submit_urb(ctrl irq) failed
[   78.652602] cdc_acm 1-10:1.0: acm_port_activate - usb_submit_urb(ctrl irq) failed

The pci_bus message is probably not relevant, the cdc_acm ... failed is both relevant and big trouble.

Fortunately, the user has the skill, experience and persistence to search for a solution. The first clue came from this stack overflow post. It appears that the dysfunctional finger-print driver enables USB auto-suspend, and this upset communications with the flight controller. Disabling auto-suspend fixed the issue.

After some further research, the user followed another stack overflow solution to disable the finger-print reader. This solved the problem permanently.

DFU Mode

If the device is in DFU (flashing) mode, it will appear in dmesg in manner of:

[640142.075534] usb 3-4.2: new full-speed USB device number 63 using xhci_hcd
[640142.166785] usb 3-4.2: New USB device found, idVendor=0483, idProduct=df11, bcdDevice=22.00
[640142.166789] usb 3-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[640142.166790] usb 3-4.2: Product: STM32  BOOTLOADER
[640142.166791] usb 3-4.2: Manufacturer: STMicroelectronics
[640142.166792] usb 3-4.2: SerialNumber: 3274337E3337

Summary

  • Serial USB issues on Linux are comparatively rare
  • There are many tools to help you
    • dmesg
    • udevadm info /dev/ttyACMO (or other appropriate device name)
  • Disabling USB auto-suspend is a good first place to look
  • Disabling Dell's dysfunctional finger-print driver may help
  • Windows inspired "solutions" like "reinstall the OS" are unlikely to help: Linux is somewhat deterministic; if it didn't work first time, it probably won't work after reinstalling either.
  • Good Google skills, ability to work methodically, listen to advice will always help
  • For mwp, the mwp "stderr" log ($HOME/mwp_stderr_YYYY-MM-DD.txt) may also help; the current version will log the important USB characteristics: 
    2021-07-15T21:01:58+0100 Registered USB device: /dev/ttyACM0, [0483:5740], Vendor: INAV, Model: FURIOUS_F35-LIGHTNING, Serial: 0x8000000, Driver: cdc_acm
    If you don't get "Vendor: INAV, Model: <obvious FC name>", then you probably have a driver issue.