Correzione driver STM32 DFU e doctor USB per flight controller

Parti dal cavo. Molti cavi USB venduti con caricatori trasportano solo alimentazione. I LED della scheda si accendono, sembra una connessione, ma computer o telefono non vedono alcun dispositivo. Se la scheda si accende e nulla compare nell'elenco, prova un cavo che sai trasferire dati.

Poi la modalità. Un flight controller STM32 ha due identità USB. Con Betaflight, INAV o ArduPilot in esecuzione appare come porta COM virtuale (su schede STM32, vendor 0483, product 5740), che i configurator aprono come serial. Nel bootloader ROM appare come dispositivo diverso, STM32 BOOTLOADER (0483:DF11), usato solo dai flasher. Un configurator non si collega in bootloader; un flasher non scrive su una scheda con firmware finché non la riavvia.

Infine driver e permesso. Ogni identità richiede il proprio driver su Windows; una scheda che configura bene può fallire il flash. Su Linux e Android serve permesso prima che un programma apra il dispositivo.

I flasher desktop della famiglia Betaflight parlano con il bootloader tramite il driver WinUSB. Se Windows non ha driver per STM32 BOOTLOADER, o un altro driver ha reclamato il dispositivo, il flasher segnala che non ha trovato DFU o si blocca riavviando in bootloader.

La correzione più rapida che usano molti piloti è ImpulseRC Driver Fixer, un piccolo programma Windows che trova un flight controller collegato e installa i driver necessari. Se non basta, metti la scheda in DFU, apri Zadig, Options › List All Devices, seleziona STM32 BOOTLOADER, scegli WinUSB come driver e Replace Driver o Install Driver. Se Gestione dispositivi mostra il bootloader con altro nome, come Guillemot STM DFU Device, un altro software ha installato un driver: disinstalla il dispositivo spuntando l'eliminazione del driver, scollega e reinstalla WinUSB.

Modifica il driver solo del bootloader. La porta COM virtuale per configurare funziona con il driver serial integrato di Windows attuale.

macOS non richiede driver per porte COM virtuali STM32 né per DFU. Se la scheda non compare, controlla cavo, hub USB e modalità.

Su Linux il dispositivo compare, ma un utente normale potrebbe non poterlo aprire. Le porte serial di solito richiedono il gruppo dialout (esci e rientra nella sessione); i bootloader DFU una regola udev per vendor 0483 product DF11. La documentazione Betaflight indica la regola da aggiungere.

Su computer, la versione web di FlySpark apre la serial del flight controller dal browser (Chrome o Edge), con le stesse regole di porta serial. Il flash non avviene nella versione web.

Android comunica con porte COM virtuali STM32, bootloader DFU e chip USB-serial comuni senza driver. Ciò che può bloccare sono OTG e la richiesta di permesso. Usa un adattatore OTG o un cavo USB-C con dati; alcuni telefoni hanno un interruttore USB OTG nelle impostazioni. Quando colleghi un dispositivo, Android chiede se FlySpark può usarlo. Se hai chiuso il prompt, il doctor USB e DFU mostra ALLOW ACCESS per richiederlo di nuovo.

L'alimentazione può confondere. Una scheda alimentata dalla batteria di volo e da USB insieme potrebbe non riavviarsi pulita ricollegando il cavo; la checklist del doctor suggerisce di scollegare la batteria, alimentare solo da USB e ricollegare.

Ci sono due modi. Da firmware in esecuzione: il comando bl della CLI Betaflight (INAV usa dfu) riavvia in bootloader, e il flasher firmware di FlySpark lo invia per te. A scheda spenta: tieni premuto BOOT (o ponta i pad BOOT su schede senza pulsante) mentre inserisci USB, poi rilascia. Su Android il doctor USB e DFU lo conferma: la scheda passa a Bootloader (DFU) con la famiglia del chip, ad esempio STM32 ROM DFU.

Una scheda lasciata in bootloader non si configura. Se il configurator non si collega dopo un flash, scollega e ricollega senza tenere BOOT.