STALL d'endpoint USB et timeout de transfert bulk : lire la capture avant de modifier le firmware

Après la réussite de l'énumération, les périphériques USB peuvent quand même échouer de façons qui semblent mystérieuses pour les développeurs applicatifs: "les lectures bulk timeout, les écritures ne se terminent jamais, les rapports HID cessent d'arriver, ou l'hôte signale un STALL d'endpoint. Ces défaillances sont souvent traitées comme des bugs de pilote ou des blocages firmware aléatoires. Une capture peut généralement cerner le problème bien plus vite." Les échecs d'endpoint sont des preuves de chemin de données. Ils surviennent après que l'hôte a appris la forme du périphérique. Cela signifie que les descripteurs peuvent être corrects tandis que le comportement de l'endpoint est quand même faux.

STALL est un signal, pas seulement une erreur

Un endpoint USB peut renvoyer STALL pour indiquer qu'il ne peut pas traiter une requête ou qu'une commande class/vendor n'est pas supportée. Les stalls d'endpoint de contrôle pendant les requêtes de classe peuvent être légitimes si la requête est invalide. Les stalls d'endpoint de données pendant le flux de transfert normal nécessitent généralement une inspection plus poussée.

Questions à la capture :

• quel endpoint a stallé
• était-ce control, bulk, interrupt ou isochrone
• quelle requête ou transfert a précédé le stall
• l'hôte a-t-il clear la condition de halt
• le trafic a-t-il repris après CLEAR_FEATURE(ENDPOINT_HALT)
• le firmware a-t-il stall intentionnellement des commandes non supportées

Sans ce contexte, « endpoint stalled » est trop vague pour agir.

Les timeouts bulk nécessitent direction et contexte de queue

Un timeout de transfert bulk peut signifier beaucoup de choses :

• l'hôte attendait des données IN mais le périphérique n'en avait pas de prête
• le périphérique attendait des données OUT mais l'application a cessé d'écrire
• le buffer d'endpoint firmware n'était pas primed
• le pilote hôte a soumis une lecture plus grande que ce que le firmware supporte
• le périphérique a NAKé jusqu'au timeout
• l'adresse ou direction de l'endpoint était fausse
• un stall précédent n'a jamais été clearé

La première chose à inspecter est la direction. Un timeout bulk IN et un timeout bulk OUT sont des cas différents. Pour IN, demandez si le périphérique a jamais renvoyé des données. Pour OUT, demandez si l'hôte a envoyé des données et si le périphérique les a acquittées.

La correction des descripteurs est nécessaire mais pas suffisante

Un descripteur peut déclarer correctement un endpoint bulk IN, et le périphérique peut quand même échouer à envoyer des données utiles. Un périphérique CDC peut s'énumérer comme port série et quand même ignorer le line coding ou l'état des lignes de contrôle. Une interface vendor peut exposer des endpoints mais exiger une commande d'initialisation avant tout mouvement de données.

Cela signifie que le débogage d'endpoint doit combiner :

• preuves de descripteurs
• requêtes de setup class ou vendor
• direction du transfert
• longueur de payload
• résultat du statut
• timing et tentatives répétées

La capture doit montrer si l'hôte demande quelque chose de déraisonnable ou si le firmware ne satisfait pas une requête valide.

Les équipes firmware doivent capturer avant et après le correctif

Pour les bugs d'endpoint, les captures avant-après ont de la valeur. La première capture prouve la défaillance. La seconde capture prouve le correctif. Une bonne comparaison montre :

• même périphérique et configuration
• mêmes adresses d'endpoint
• même motif de requête hôte
• l'ancienne capture stall ou timeout
• la nouvelle capture se termine et porte le payload attendu

Cela rend la revue de régression firmware bien plus facile. Cela donne aussi aux équipes de support un artefact reproductible quand les clients signalent que « l'USB se fige aléatoirement ».

Où Bus Scope s'inscrit

Bus Scope vise les preuves USB, pas l'éparpillement de protocoles génériques. Pour les cas STALL et timeout d'endpoint, il doit garder proches le détail des paquets, les métadonnées d'endpoint, les octets bruts, le type de transfert et l'interprétation de classe.

La sortie utile est :

• endpoint et direction
• type de transfert
• requête ou transfert avant la défaillance
• preuve de statut
• payload brut autour de la défaillance
• si le problème suit l'énumération, le setup de classe ou le trafic applicatif

C'est l'information dont les ingénieurs firmware ont besoin avant de toucher à la logique de buffer d'endpoint ou au comportement de retry côté hôte.

Si votre requête de recherche est « USB bulk transfer timeout » ou « USB endpoint stalled », ne commencez pas par réécrire toute la pile du périphérique. Capturez d'abord la preuve d'endpoint.