STM32 DFU driver fix and a USB doctor for flight controllers

Start with the cable. Many USB cables sold with chargers and gadgets only carry power. The board's LEDs light up, which looks like a connection, but the computer or phone never sees a device. If a board powers on and nothing appears in the device list, try a cable you know transfers files.

Next, the mode. An STM32 flight controller has two USB identities. Running Betaflight, INAV or ArduPilot it appears as a virtual COM port (on STM32 boards, vendor 0483, product 5740), which configurators open as a serial port. In its ROM bootloader it appears as a completely different device, STM32 BOOTLOADER (0483:DF11), which only flashers use. A configurator cannot connect to a board in bootloader mode, and a flasher cannot write to a board that is running its firmware until it reboots it.

Then the driver and the permission. Each identity needs its own driver on Windows, so a board that connects fine for configuring can still fail to flash. On Linux and Android the device needs permission before a program can open it.

Desktop flashers in the Betaflight family talk to the bootloader through the WinUSB driver. If Windows has no driver for STM32 BOOTLOADER, or another program's driver has claimed it, the flasher reports that no DFU device was found or hangs while rebooting into the bootloader.

The quickest fix most pilots use is ImpulseRC Driver Fixer, a small Windows program that finds a plugged-in flight controller and installs the drivers it needs. If it does not help, put the board in DFU mode, open Zadig, choose Options › List All Devices, select STM32 BOOTLOADER, choose WinUSB as the target driver and press Replace Driver or Install Driver. If Device Manager shows the bootloader under another name, such as Guillemot STM DFU Device, a driver installed by other software has claimed it: uninstall that device with the option to delete its driver ticked, unplug, and install WinUSB again.

Only change the driver for the bootloader device. The virtual COM port used for configuring works with the serial driver built into current Windows versions.

macOS needs no driver for STM32 virtual COM ports or for DFU. If a board does not appear, check the cable, the USB hub, and the mode.

On Linux the device appears, but a normal user may not be allowed to open it. Serial ports usually need your user to be in the dialout group (log out and back in afterwards), and DFU bootloaders need a udev rule that grants access to vendor 0483 product DF11. The Betaflight documentation gives the rule to add.

On a computer, FlySpark's web version opens the flight controller's serial port through the browser (Chrome or Edge), so the same serial-port rules apply. Flashing is not done in the web version.

Android talks to STM32 virtual COM ports, DFU bootloaders and common USB-serial chips without any driver. What can stop it is the OTG link and the permission prompt. Use an OTG adapter or a USB-C to USB-C data cable; some phones have a USB OTG switch in their settings that must be on. When a device is plugged in, Android asks whether FlySpark may use it. If you dismissed the prompt, the USB and DFU doctor shows ALLOW ACCESS on that device to ask again.

Power can confuse things too. A board that is powered by the flight battery and USB at the same time may not restart cleanly when you replug the cable, so the doctor's checklist suggests unplugging the battery, powering the board from USB only, and plugging it in again.

There are two ways. From running firmware: Betaflight's CLI command bl (INAV uses dfu) reboots the board into its bootloader, and FlySpark's firmware flasher sends it for you. From power-off: hold the BOOT button (or bridge the BOOT pads on boards without a button) while plugging in USB, then release. On Android the USB and DFU doctor confirms it: the card changes to Bootloader (DFU) with the chip family, such as STM32 ROM DFU.

A board left in bootloader mode will not configure. If the configurator cannot connect after a flash, unplug and plug it in again without holding BOOT.