If Betaflight (or Cleanflight, or any other thing) can’t access the device, some thing might “steal” the devicefile. My Betflight switches to “DFU” if I connect the flightcontroller. In this case the darn computer thinks it got a modem attached and hands the device over to ModemManager.

The Betaflight Git page proposes to stop ModemManager to prevent the hostile takeover:

sudo systemctl stop ModemManager.service

But this is tedious… Here is how to make UDEV ignore that device without messing with ModemManager after each reboot:

After plugging in the flightcontroller use dmesg to identify idVendor and idProduct

[440554.065013] usb 1-1.2: New USB device found, idVendor=0483, idProduct=5740
[440554.065019] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[440554.065022] usb 1-1.2: Product: STM32 Virtual COM Port
[440554.065026] usb 1-1.2: Manufacturer: STMicroelectronics
[440554.065028] usb 1-1.2: SerialNumber: 206632625733

In this case we have idVendor=0483, idProduct=5740

Now check your udev-rules for 70-mm-usb-device-blacklist.rules or something similar. Here is the content of my file /etc/udev/rules.d/70-mm-usb-device-blacklist.rules

# make modemmanager ignore FlighControl Boards

ACTION!=”add|change|move”, GOTO=”mm_usb_device_blacklist_end”
SUBSYSTEM!=”usb”, GOTO=”mm_usb_device_blacklist_end”

# Product: STM32 Virtual COM Port
# idVendor=0483, idProduct=5740
ATTRS{idVendor}==”0483″, ATTRS{idProduct}==”5740″, ENV{ID_MM_DEVICE_IGNORE}=”1″

LABEL=”mm_usb_device_blacklist_end”

After that just restart the udev daemon and be happy 😉

For different boards you might need to identify the IDs and add an appropriate ATTRS-line to the file.