Échec de mise à jour firmware USB DFU : débogage du mode bootloader, transferts de contrôle, timeouts et reconnexions

Les échecs de mise à jour firmware sont stressants car un périphérique peut disparaître, entrer en mode bootloader, se reconnecter avec un VID/PID différent, ou rester bloqué sur « initializing », « erasing », « downloading » ou « rebooting ». Les utilisateurs cherchent « USB DFU failed », « firmware update stuck initializing », « USB bootloader not detected », « DFU device not found » ou « firmware update timeout » car l'updater montre rarement la machine à états USB.

Les flux USB Device Firmware Upgrade sont généralement construits sur des transferts de contrôle et des transitions d'état du périphérique. L'updater peut parler au firmware applicatif normal, commander un reboot en mode bootloader, attendre qu'un autre périphérique USB s'énumère, envoyer des blocs firmware, demander le statut, puis commander un detach ou un reset.

Bus Scope est utile car chaque étape est visible sur le bus si on capture depuis le début.

Une mise à jour firmware est souvent deux périphériques

Beaucoup de produits s'énumèrent comme un périphérique USB en fonctionnement normal et comme un autre en mode bootloader. Le VID/PID, la chaîne produit, les interfaces et la liaison de pilote peuvent changer.

La séquence peut ressembler à :

1. Le périphérique normal est connecté.
2. L'updater envoie la commande d'entrée en bootloader.
3. Le périphérique se déconnecte.
4. Le périphérique bootloader s'énumère.
5. L'updater envoie les blocs DFU.
6. Le périphérique rapporte le statut.
7. Le périphérique reset en mode normal.

Si l'utilisateur démarre la capture après que le périphérique a disparu, la transition importante est déjà perdue.

Points de défaillance fréquents

Les mises à jour DFU échouent quand :

• le mode bootloader n'est jamais entré
• le bootloader s'énumère mais le pilote ne se lie pas
• l'updater attend un VID/PID mais le périphérique en expose un autre
• transfert de contrôle qui stall
• taille de bloc firmware erronée
• timeout du périphérique pendant l'effacement
• polling de statut trop agressif
• déconnexion du périphérique pendant le téléchargement
• problème de câble ou d'alimentation causant un reset
• contrôle de sécurité/version qui rejette l'image

L'updater peut rapporter tout cela comme « firmware update failed ».

Preuves de transfert de contrôle

Les opérations de classe DFU utilisent des transferts de contrôle. Une trace peut montrer si l'updater a envoyé des données de download, demandé le statut, clear l'état, ou hit un stall.

Cherchez :

• DFU_DNLOAD
• DFU_UPLOAD
• DFU_GETSTATUS
• DFU_CLRSTATUS
• DFU_ABORT
• reset ou déconnexion du périphérique
• STALL sur l'endpoint zéro

Si un transfert de contrôle stall au même bloc à chaque fois, la validité de l'image firmware, la taille de bloc, le comportement d'effacement/écriture flash, ou un bug bootloader devient probable.

Timing de reconnexion

Après être entré en mode bootloader, l'updater doit attendre la ré-énumération. S'il cherche trop tôt, il peut dire « device not found » alors que le bootloader apparaît une seconde plus tard.

Une trace de bus montre le timing :

• temps de détachement du périphérique normal
• temps d'attachement du bootloader
• lectures de descripteurs
• liaison de pilote
• première requête DFU

Cette preuve aide à séparer un timeout d'updater d'une défaillance du périphérique.

Problèmes de liaison de pilote

Sous Windows, un bootloader peut nécessiter un pilote différent du périphérique normal. Sous Linux, les permissions peuvent différer selon le VID/PID. Sous macOS, le comportement de classe peut différer encore.

Si le bootloader s'énumère correctement mais que l'updater ne peut pas l'ouvrir, le problème est au-dessus de l'énumération USB de base. Si le bootloader ne s'énumère jamais, déboguez d'abord firmware, câble, reset et alimentation.

Checklist de débogage

Suivez ce processus :

1. Capturez avant de démarrer l'updater.
2. Enregistrez les descripteurs du périphérique normal.
3. Capturez la commande d'entrée en bootloader.
4. Observez la déconnexion et la ré-énumération du bootloader.
5. Enregistrez le VID/PID et descripteurs du bootloader.
6. Inspectez les transferts de contrôle DFU.
7. Trouvez le premier STALL, timeout, reset ou réponse manquante.
8. Comparez le numéro de bloc défaillant si reproductible.
9. Vérifiez la liaison de pilote et les permissions après énumération.
10. Conservez la timeline complète de la mise à jour avant de la réduire.

Diagnostic final

Les échecs USB DFU sont des échecs de machine à états. La cause racine peut être l'entrée en bootloader, la ré-énumération, la liaison de pilote, le comportement des transferts de contrôle DFU, la taille de bloc, le timing flash, la validation d'image, ou le timing de reset.

Bus Scope aide en exposant la mise à jour firmware comme preuve USB, et non comme une simple barre de progression qui s'arrête.