Erreur de STALL USB et débogage de transfert de contrôle

Les transferts de contrôle USB sont la première vraie conversation entre hôte et périphérique. L'énumération en dépend. Le setup de classe en dépend. L'initialisation vendor en dépend souvent. Quand les transferts de contrôle échouent, l'utilisateur ne voit parfois que « device not recognized » ou « driver failed », mais la preuve est généralement dans le setup packet.

Pour les ingénieurs firmware, apprendre à lire bmRequestType, bRequest, wValue, wIndex et wLength est l'un des moyens les plus rapides de passer du tâtonnement à un correctif précis.

Le setup packet est le contrat de requête

Un setup packet USB indique au périphérique :

• direction du transfert
• type de requête : standard, class, vendor ou réservé
• destinataire : device, interface, endpoint ou autre
• code de requête
• champ value
• champ index
• longueur de données attendue

Si le firmware décode mal ces champs, il peut renvoyer le mauvais descripteur, stall une requête valide ou accepter une commande invalide. Si l'hôte envoie une requête inattendue, la capture le montre aussi.

GET_DESCRIPTOR est le premier endroit où chercher

Pendant l'énumération, l'hôte envoie des requêtes de descripteurs standard. Un motif fréquent inclut :

• requête de descripteur de périphérique
• requête de descripteur de configuration
• requête de descripteur string
• requête de descripteur de rapport HID pour les périphériques HID
• requête de descripteur BOS sur les hôtes récents

Dans le setup packet, bRequest identifie GET_DESCRIPTOR, tandis que wValue inclut le type de descripteur et l'index. wIndex peut identifier le language ID pour les descripteurs string ou l'interface pour les descripteurs spécifiques à la classe. wLength indique combien d'octets l'hôte attend.

Quand la longueur de réponse du descripteur est fausse, ou que le firmware renvoie moins d'octets que nécessaire, l'énumération peut échouer plus tard d'une façon qui semble sans rapport.

Les erreurs de direction coûtent cher

Les transferts de contrôle ont une direction. Les requêtes device-to-host renvoient des données. Les requêtes host-to-device portent des données ou configurent un état. Si le firmware traite une requête de lecture comme une écriture, ou renvoie des données pendant une requête d'écriture, l'hôte ne devinera pas gentiment l'intention.

Surveillez :

• direction IN mais pas de phase data
• direction OUT mais le firmware attend pour envoyer des données
• phase status de longueur zéro manquante
• STALL sur une requête standard valide
• requête de classe traitée par la mauvaise interface

La capture doit montrer la requête, la phase data et la phase status.

Les requêtes de classe et vendor nécessitent le contexte d'interface

Après l'énumération, les pilotes de classe envoient des requêtes spécifiques à la classe. CDC peut envoyer des requêtes de line coding. HID peut demander des descripteurs de rapport ou des feature reports. Les outils vendor peuvent envoyer des commandes d'initialisation. La même valeur bRequest peut signifier des choses différentes selon le type de requête et le destinataire.

Inspectez :

• type de requête
• destinataire
• numéro d'interface dans wIndex
• numéro d'endpoint quand le destinataire est un endpoint
• octets de charge utile
• réponse ou stall

Si un périphérique composite a plusieurs interfaces, router la requête vers la mauvaise interface est un bug courant.

Comment Bus Scope doit aider

Bus Scope est construit pour les preuves USB. Le débogage de transfert de contrôle exige les champs de setup décodés et les octets bruts ensemble. La meilleure vue permet aux ingénieurs firmware de lire les champs sémantiques tout en validant les octets exacts du paquet.

Une bonne session Bus Scope pour le débogage de transfert de contrôle doit répondre à :

• quel setup packet a échoué ?
• était-il standard, class ou vendor ?
• quel descripteur ou interface a été demandé ?
• le périphérique a-t-il renvoyé la longueur attendue ?
• le firmware a-t-il stall intentionnellement ou incorrectement ?
• l'étape d'énumération suivante dépendait-elle de cette réponse ?

Le problème peut être décrit comme « USB control transfer failed », mais le correctif vit généralement dans un setup packet à cinq champs.