Débogage USB Mass Storage BOT : CBW, CSW, données sense et transferts échoués
Comment déboguer les échecs de Bulk-Only Transport USB Mass Storage via les Command Block Wrappers, Command Status Wrappers et données sense.
Les périphériques USB Mass Storage semblent simples côté utilisateur: "branchez une clé USB, un data logger, un périphérique de mise à jour firmware, ou un gadget de stockage embarqué, et un disque apparaît. Quand ça échoue, l'erreur peut être vague : périphérique non prêt, erreur d'I/O, demande de format, échec de montage ou disque qui disparaît." En dessous, beaucoup de périphériques utilisent le Bulk-Only Transport. BOT a un flux de commandes reconnaissable: "Command Block Wrapper, phase data, Command Status Wrapper. Si ce motif se casse, la capture peut généralement montrer où."
Comprendre le flux BOT
Le motif normal est :
- l'hôte envoie CBW sur bulk OUT
- phase data optionnelle sur bulk IN ou OUT
- le périphérique envoie CSW sur bulk IN
Le CBW porte une commande SCSI. Le CSW rapporte le statut de la commande. Si la commande échoue, l'hôte peut émettre REQUEST SENSE pour savoir pourquoi.
Preuves utiles :
- signature CBW
- tag de commande
- longueur de transfert de données
- flag de direction
- octets de commande SCSI
- longueur de phase data
- signature CSW
- statut CSW
- residue
- données sense après défaillance
Si les tags ne correspondent pas, l'hôte ne peut pas se fier au statut. Si la longueur de données ne correspond pas au comportement, des timeouts ou stalls peuvent suivre.
Les données sense expliquent beaucoup de défaillances
Une commande SCSI échouée n'est pas la fin du diagnostic. Les données sense donnent souvent la vraie raison :
- not ready
- medium error
- illegal request
- write protected
- logical block address hors plage
- unit attention après reset
Les équipes firmware doivent capturer la commande qui a échoué et la réponse sense qui a suivi. Un échec de montage côté hôte peut être une réponse valide à une condition de stockage rapportée par le firmware.
STALL d'endpoint et récupération après reset
BOT a un comportement de récupération défini. Si un endpoint stall ou qu'une commande échoue gravement, l'hôte peut clear le halt d'endpoint ou émettre un reset de stockage de masse. Un périphérique qui ne récupère pas correctement peut sembler disparaître ou nécessiter un débranchement.
Inspectez :
- quel endpoint a stallé
- si l'hôte a envoyé clear feature
- si un reset BOT s'est produit
- si le flux CBW/CSW suivant a repris
- si les tags sont restés cohérents
Cette preuve vaut mieux que de deviner les machines d'état du firmware.
Où Bus Scope s'inscrit
Bus Scope est un atelier d'inspection USB. Pour les cas de stockage de masse, les octets bruts seuls ne suffisent pas ; la structure BOT décodée et le statut des transferts aident les ingénieurs à trouver la faute plus vite.
Un bon rapport Bus Scope pour le débogage BOT doit répondre à :
- quelle commande SCSI a échoué ?
- la phase data a-t-elle matché la direction et longueur du CBW ?
- le CSW est-il arrivé ?
- le tag du CSW a-t-il matché le tag du CBW ?
- quelles données sense ont suivi ?
- la récupération après reset a-t-elle fonctionné ?
Pour des requêtes comme « USB mass storage BOT failed », « CBW CSW mismatch » ou « USB flash drive I/O error firmware », c'est le chemin du symptôme utilisateur vers la preuve de bus.