Débogage de descripteurs USB pour périphériques HID et CDC

Les périphériques HID et CDC sont populaires car ils permettent aux équipes firmware de livrer des interfaces USB utiles sans écrire un pilote personnalisé pour chaque hôte. Cette commodité dépend de descripteurs précis. Quand un clavier HID, un capteur, un pont série ou un périphérique composite échoue, la cause racine est souvent visible dans la preuve de descripteurs avant d'apparaître dans l'application.

Le débogage de descripteurs n'est pas glamour, mais c'est l'un des moyens les plus rapides de résoudre les cas de support USB.

HID : le report descriptor est le contrat

Pour les périphériques HID, l'hôte a besoin de plus que des informations d'endpoint. Il a besoin du HID report descriptor. Ce descripteur définit les report IDs, usages, tailles, comptes, plages logiques et la façon dont les octets doivent être interprétés.

Erreurs HID fréquentes :

• longueur de rapport qui ne correspond pas aux charges utiles d'interrupt réelles
• report ID utilisé dans le firmware mais pas déclaré de façon cohérente
• valeurs logical min et max qui ne correspondent pas à la représentation des données
• usage page ou usage qui ne correspond pas aux attentes de l'hôte
• intervalle d'endpoint irréaliste pour le comportement du périphérique
• hypothèses de boot protocol en conflit avec le comportement de report protocol

Une erreur côté hôte peut sembler vague. Une capture qui montre les octets de descripteur et les transferts d'interrupt peut rendre le décalage évident.

CDC : la disposition des interfaces compte

Les périphériques CDC ACM exposent généralement une interface de communication et une interface de données. L'hôte attend un ensemble cohérent de descripteurs et de requêtes spécifiques à la classe. Un descripteur fonctionnel manquant, une mauvaise interface association ou un décalage d'endpoint peut empêcher le port série virtuel d'apparaître.

Preuves à inspecter :

• interface class et subclass
• descripteurs CDC header, ACM, union et call management
• endpoint de notification
• endpoints bulk IN et OUT
• SET_LINE_CODING
• SET_CONTROL_LINE_STATE
• transferts de données après configuration

Si le port série apparaît mais qu'aucun octet ne circule, le problème peut être le comportement de l'endpoint ou le protocole applicatif. Si le port série n'apparaît jamais, les descripteurs et requêtes de classe sont le premier endroit où regarder.

Les périphériques composites exigent plus de discipline

Les périphériques composites peuvent combiner HID, CDC, stockage de masse, interfaces vendor et plus encore. C'est utile, mais cela multiplie les modes de défaillance. Une erreur de descripteur dans une interface peut affecter la liaison hôte pour le périphérique entier.

Pour le débogage composite, inspectez :

• longueur totale de configuration
• numéros d'interfaces
• descripteurs Interface Association
• unicité des endpoints
• placement des descripteurs spécifiques à la classe
• requêtes de l'hôte par interface

Ne supposez pas que « le firmware envoie les bons octets » tant que la capture ne prouve pas que l'hôte a vu la bonne structure.

Pourquoi les octets bruts et l'interprétation de classe comptent tous les deux

Les octets bruts sont la vérité du terrain. L'interprétation de classe les rend utilisables. Un bon outil de diagnostic USB doit montrer les deux. Les ingénieurs ont besoin de voir les octets exacts du descripteur quand quelque chose ne va pas, mais ils ont aussi besoin des champs décodés pour éviter de compter manuellement les décalages à chaque cas.

Le meilleur flux est :

1. inspecter l'arborescence de descripteurs décodée
2. sauter aux octets bruts pour les champs suspects
3. comparer les requêtes de l'hôte avec les réponses du firmware
4. inspecter les transferts d'endpoint après configuration
5. enregistrer la session pour reproduction ou transmission au support

Ce flux garde le diagnostic lié aux preuves.

Où Bus Scope s'inscrit

Bus Scope est conçu pour les équipes firmware, laboratoires hardware et vendeurs de périphériques qui ont besoin d'une réponse reproductible à la question de l'échec du trafic USB. Il garde dans un même atelier le contexte device explorer, le détail des paquets, les octets bruts, les descripteurs, les observations de classe, les filtres et les sessions .bscope enregistrées.

Pour les cas HID et CDC, Bus Scope doit aider à répondre :

• l'énumération s'est-elle terminée ?
• les descripteurs correspondent-ils à la classe visée ?
• l'hôte a-t-il envoyé les requêtes de classe attendues ?
• les transferts d'endpoint correspondent-ils aux attentes de rapport ou de line coding ?
• est-ce un problème firmware, pilote hôte ou protocole applicatif ?

C'est la différence entre voir « driver failed » et comprendre quel contrat USB a été rompu.