STALL de transfert de contrôle USB : débogage de setup packets, endpoint zéro et requêtes échouées

Les transferts de contrôle USB sont la fondation de l'énumération et de la gestion des périphériques. Ils lisent les descripteurs, définissent les adresses, sélectionnent les configurations, changent d'interface, émettent des requêtes de classe et envoient des commandes vendor. Quand un transfert de contrôle stall, les utilisateurs peuvent voir « USB device not recognized », « control transfer failed », « libusb control transfer error », « endpoint zero stalled » ou un outil de mise à jour firmware qui s'arrête à l'initialisation.

Les recherches comme « USB control transfer STALL », « USB setup packet debugging », « endpoint zero stall », « GET_DESCRIPTOR failed » ou « vendor request stalled » signifient généralement que la défaillance s'est produite avant que le trafic bulk, interrupt ou isochrone normal ait pu se dérouler.

Bus Scope est utile car le setup packet explique la requête. Sans lui, un STALL n'est qu'une erreur générique.

Ce que contient un transfert de contrôle

Un transfert de contrôle USB a des étapes :

1. Setup stage
2. Data stage (optionnelle)
3. Status stage

Le setup packet contient :

• bmRequestType
• bRequest
• wValue
• wIndex
• wLength

Ces champs définissent la direction, le type de requête, le destinataire, le code de requête, le type de descripteur, l'interface, l'endpoint et la longueur de données attendue.

Si le périphérique stall, inspectez d'abord le setup packet.

L'endpoint zéro est particulier

L'endpoint zéro existe pour chaque périphérique USB. Il est utilisé pendant l'énumération et les opérations de contrôle. Si l'endpoint zéro se comporte incorrectement, l'hôte peut ne jamais lier le pilote normal.

Les défaillances d'endpoint zéro peuvent apparaître comme :

• requête de descripteur de périphérique échouée
• lecture de descripteur de configuration échouée
• requête de descripteur string stalled
• SET_CONFIGURATION échoué
• requête spécifique à la classe échouée
• commande vendor échouée

Pour un firmware personnalisé, la correction de l'endpoint zéro n'est pas négociable.

Le STALL peut être valide

Tout STALL n'est pas un bug. Un périphérique peut légitimement stall une requête non supportée. La question est de savoir si l'hôte attendait un support et si l'état du périphérique permet la requête.

Exemples :

• requête vendor non supportée : STALL peut être correct
• index de descripteur invalide : STALL peut être correct
• requête de classe requise pendant l'énumération : STALL peut casser la liaison de pilote
• requête DFU dans le mauvais état : STALL peut indiquer un décalage de machine à états

La signification dépend du type de requête et du timing.

Échecs de requêtes de descripteurs

Les STALL de descripteurs sont fréquents dans les piles USB personnalisées. Surveillez :

• mauvais type de descripteur dans wValue
• index de string non supporté
• décalage de longueur totale de configuration
• le périphérique renvoie moins de données que demandé incorrectement
• le périphérique ne gère pas les lectures initiales courtes de descripteurs
• le firmware suppose un seul motif de requête hôte

Différents OS demandent les descripteurs dans des ordres différents. Un périphérique qui marche sous Linux peut stall une requête que Windows envoie pendant l'énumération.

Requêtes de classe et vendor

Les requêtes de classe sont interprétées par la classe USB. HID, CDC, DFU, Audio, Video, Mass Storage et les périphériques vendor ont tous des attentes de requêtes.

Exemples courants :

• HID GET_REPORT
• HID SET_REPORT
• CDC SET_LINE_CODING
• CDC SET_CONTROL_LINE_STATE
• DFU GETSTATUS
• contrôles UVC probe/commit
• commandes de bootloader vendor

Si une requête de classe stall, vérifiez si le numéro d'interface dans wIndex correspond à l'interface visée. Les périphériques composites échouent fréquemment parce que l'hôte envoie la requête à une interface et que le firmware en traite une autre.

Checklist de débogage

Suivez ce flux :

1. Capturez dès le branchement.
2. Trouvez le premier STALL de transfert de contrôle.
3. Décodez les champs du setup packet.
4. Déterminez si la requête est standard, class ou vendor.
5. Déterminez le destinataire : device, interface, endpoint ou autre.
6. Vérifiez wValue, wIndex et wLength.
7. Comparez aux descripteurs et à l'état courant du périphérique.
8. Vérifiez si le STALL est attendu ou fatal.
9. Cherchez une requête de récupération comme clear feature ou reset.
10. Comparez l'ordre des requêtes de l'OS hôte si le comportement diffère entre plateformes.

Diagnostic final

Un STALL de transfert de contrôle USB n'est pas suffisant à lui seul. Le setup packet est l'ancre du diagnostic. Il indique quelle requête a échoué, quel destinataire était visé, combien de données étaient attendues et si l'état du périphérique rendait la requête valide.

Bus Scope aide à exposer l'endpoint zéro et les preuves de setup packet pour que les équipes firmware, pilote et QA puissent déboguer précisément les échecs de chemin de contrôle.