Récupération de halt d'endpoint USB : CLEAR_FEATURE, boucles STALL, échecs bulk et reset de pilote

Les halts d'endpoint USB sont une source fréquente de bugs de type « marche une fois, puis échoue ». Un transfert bulk stall, le pilote clear le halt, le périphérique stall à nouveau, et finalement l'application signale timeout, erreur d'I/O, reset du périphérique ou déconnexion. Les utilisateurs cherchent « USB endpoint halt », « CLEAR_FEATURE ENDPOINT_HALT », « USB STALL loop », « bulk endpoint stalled » ou « libusb clear halt » quand le périphérique ne disparaît pas simplement mais cesse d'accepter le trafic sur un endpoint précis.

Bus Scope est utile car la récupération de halt d'endpoint est une séquence, pas un événement unique. Vous devez voir le premier STALL, la requête de récupération de l'hôte, ce que le périphérique a fait après, et si la même commande a causé le halt à nouveau.

Ce que signifie halt d'endpoint

Un halt d'endpoint signifie que l'endpoint est stalled et ne peut pas continuer des transferts normaux tant que la condition de halt n'est pas cleared. L'hôte peut émettre :

CLEAR_FEATURE(ENDPOINT_HALT)

vers l'endpoint affecté. Après cela, le data toggle et l'état côté périphérique peuvent devoir être cohérents pour que le transfert reprenne correctement.

Si le firmware clear uniquement le flag hardware USB mais pas son état de protocole interne, le transfert suivant peut à nouveau échouer.

STALL vs timeout

STALL est explicite. Timeout signifie pas de complétion dans le délai attendu. Un timeout peut survenir parce que l'endpoint n'a jamais répondu, que le périphérique a continué à NAKer, ou que le périphérique s'est déconnecté.

La récupération de halt d'endpoint commence par un STALL. Si l'hôte ne voit jamais de STALL et ne voit qu'un timeout, le chemin de récupération est différent.

Halt d'endpoint bulk

Les endpoints bulk stallent souvent quand une commande est invalide, qu'une phase de protocole est fausse, ou que le firmware détecte une erreur.

Exemple :

Host -> Device bulk OUT command
Device -> Host STALL sur bulk IN
Host -> Device CLEAR_FEATURE(ENDPOINT_HALT)
Host retente bulk IN
Device stall à nouveau

Ce motif suggère que le halt d'endpoint est un symptôme de l'état de protocole du périphérique, pas seulement une erreur de bus transitoire.

La récupération doit correspondre à la direction de l'endpoint

Les adresses d'endpoint incluent la direction. L'endpoint 0x81 et l'endpoint 0x01 sont des directions différentes. Clear le mauvais endpoint ne récupérera pas le pipe stalled.

Vérifiez :

• quel endpoint a stallé
• direction IN ou OUT
• l'hôte a-t-il clear le bon endpoint
• les transferts ont-ils repris après le clear
• le data toggle / état s'est-il récupéré correctement

C'est une source fréquente de signalements trompeurs « clear halt did not work ».

Boucles STALL répétées

Un STALL répété après clear signifie généralement que la cause sous-jacente persiste :

• l'hôte renvoie une commande non supportée
• la machine à états du firmware reste en erreur
• le périphérique attend un reset avant retry
• l'hôte lit depuis le mauvais endpoint
• longueur ou checksum de commande faux
• data toggle / état d'endpoint incohérent
• le firmware nécessite une requête class/vendor avant de reprendre

La trace doit inclure la commande avant le premier STALL, pas seulement les tentatives de récupération.

Comportement de reset du pilote

Si la récupération clear-halt échoue, les pilotes peuvent reset le périphérique. Cela peut masquer l'erreur d'endpoint d'origine. L'utilisateur voit une reconnexion ou disparition du périphérique, mais la preuve du bus montre que la vraie première défaillance était une boucle STALL.

Conservez la chronologie :

1. Dernière commande réussie.
2. Premier STALL.
3. Tentative de clear halt.
4. Retry.
5. STALL ou timeout répété.
6. Reset ou déconnexion du périphérique.

Checklist de débogage

Suivez ce flux :

1. Identifiez l'endpoint qui a stallé.
2. Enregistrez la direction et le type de transfert de l'endpoint.
3. Inspectez la commande ou le transfert immédiatement avant le STALL.
4. Vérifiez si l'hôte envoie CLEAR_FEATURE(ENDPOINT_HALT).
5. Confirmez qu'il cible le bon endpoint.
6. Vérifiez si le transfert reprend.
7. Si le STALL se répète, inspectez l'état du protocole firmware.
8. Cherchez un reset du périphérique après récupération échouée.
9. Comparez avec une séquence de commandes réputée bonne.
10. Conservez assez de contexte avant le STALL.

Diagnostic final

La récupération de halt d'endpoint USB est un problème de machine à états. CLEAR_FEATURE(ENDPOINT_HALT) peut clear la condition d'endpoint USB, mais ne corrige pas automatiquement l'état de protocole firmware, les commandes invalides, les mauvais endpoints ou la logique de retry du pilote.

Bus Scope aide à exposer la séquence complète de halt et récupération pour que les échecs d'endpoint soient diagnostiqués à partir du comportement USB réel.