Timeout de requête de contrôle vendor-specific USB

Les requêtes de contrôle USB vendor-specific sont fréquentes dans les outils firmware, utilitaires de calibration, logiciels de test en usine, bootloaders, modes debug et périphériques personnalisés. Quand elles échouent, les applications signalent souvent seulement « control transfer timeout », « vendor request failed », « device not responding » ou LIBUSB_ERROR_TIMEOUT. Les utilisateurs cherchent « USB vendor request timeout », « bmRequestType debugging », « control transfer endpoint zero timeout » ou « vendor-specific USB command failed » car la défaillance est dans un protocole privé que l'OS ne peut pas expliquer.

Bus Scope est utile car chaque requête de contrôle vendor-specific a toujours un setup packet standard. Même si la signification de la commande est privée, la structure du transfert est visible.

Champs du setup packet

Une requête de contrôle inclut :

• bmRequestType
• bRequest
• wValue
• wIndex
• wLength

Pour les requêtes vendor, bmRequestType identifie le type vendor et la direction. bRequest, wValue et wIndex sont définis par le firmware du périphérique.

Si la direction ou la longueur est fausse, le périphérique peut stall ou timeout.

Timeout vs STALL

STALL signifie que le périphérique a explicitement rejeté la requête. Timeout signifie que l'hôte n'a pas reçu la complétion dans le délai.

Le timeout peut signifier :

• firmware bloqué en traitant la commande
• périphérique resete pendant la requête
• décalage de direction
• hôte attendait des données mais le périphérique n'en a pas envoyé
• périphérique attendait des données OUT mais l'hôte a demandé IN
• commande valide uniquement dans un autre état
• effacement flash ou opération capteur trop long

La trace doit montrer s'il y a eu une phase data et si le périphérique a disparu après.

Commandes bootloader et mise à jour firmware

Les requêtes vendor déclenchent souvent l'entrée en bootloader, effacement flash, écriture firmware, reset ou polling de statut. Ces commandes peuvent légitimement prendre du temps, mais le timeout de l'hôte doit correspondre au comportement attendu.

Si une requête timeout toujours avant une reconnexion, le périphérique peut en fait reset avec succès. Si elle timeout et ne se ré-énumère jamais, le firmware peut être bloqué.

Checklist de débogage

Suivez ce flux :

1. Capturez avant d'envoyer la commande vendor.
2. Décodez les champs du setup packet.
3. Confirmez que la direction matche la phase data attendue.
4. Vérifiez wLength.
5. Cherchez les octets de la phase data.
6. Cherchez STALL, timeout, reset ou déconnexion.
7. Vérifiez si le périphérique se ré-énumère dans un autre mode.
8. Comparez la séquence de commandes avec un outil réputé bon.
9. Augmentez le timeout seulement après avoir prouvé que la commande prend légitimement plus de temps.
10. Conservez la séquence de requêtes vendor avant et après la défaillance.

Diagnostic final

Les timeouts de requêtes de contrôle vendor-specific sont des échecs de protocole privé, mais la preuve USB reste visible. Le setup packet, la direction, la longueur, le timing, le comportement de reset et la réponse de l'endpoint zéro montrent si la forme de la requête hôte ou l'état firmware du périphérique est responsable.

Bus Scope aide à transformer un échec de commande firmware privé en preuve USB inspectable.