Débogage de périphérique composite USB : numéros d'interface, IAD, endpoints et liaison de pilote

Comment déboguer les périphériques composites USB quand une interface marche, une autre échoue, ou que l'hôte lie le mauvais pilote.

USB, périphérique composite, IAD, interface, liaison pilote, descripteur

Les périphériques composites USB sont à la fois pratiques et dangereux. Un seul périphérique peut exposer des contrôles HID, du CDC série, du stockage de masse, des endpoints vendor, de l'audio, de la vidéo ou des interfaces de diagnostic. Quand tout est décrit correctement, l'hôte lie les bons pilotes et chaque fonction marche. Quand un seul champ de descripteur est faux, le périphérique entier peut sembler peu fiable.

Les recherches comme « USB composite device not recognized », « CDC interface not showing », « HID works but serial does not » ou « wrong driver binding USB interface » pointent généralement vers la structure des descripteurs, la numérotation d'interfaces, l'affectation des endpoints ou le comportement de l'Interface Association Descriptor.

Les périphériques composites nécessitent une configuration cohérente

Le descripteur de configuration est la carte de niveau supérieur. Il doit décrire la longueur totale, le nombre d'interfaces, les attributs d'alimentation, et tous les descripteurs d'interface et d'endpoint imbriqués. Si wTotalLength est faux, l'hôte peut ne pas lire toutes les fonctions. Si le nombre d'interfaces est faux, l'hôte peut ignorer les interfaces suivantes. Si les adresses d'endpoints se télescopent, les transferts deviennent ambigus ou invalides.

Inspectez :

  • longueur totale de configuration
  • nombre d'interfaces
  • numéros d'interfaces
  • alternate settings
  • adresses d'endpoints
  • directions d'endpoints
  • valeurs class, subclass, protocol
  • ordre des descripteurs

Une capture doit montrer si l'hôte a demandé la configuration complète et quels octets le périphérique a renvoyés.

L'IAD aide à regrouper les interfaces liées

Les Interface Association Descriptors sont souvent utilisés pour regrouper plusieurs interfaces appartenant à une même fonction, comme la communication CDC plus les données CDC. Sans regroupement correct, l'hôte peut lier les pilotes de façon incorrecte ou n'exposer qu'une partie de la fonction.

Preuves IAD à inspecter :

  • premier numéro d'interface
  • nombre d'interfaces
  • function class, subclass, protocol
  • placement avant les interfaces regroupées
  • cohérence avec les descripteurs d'interface réels

Si le CDC série n'apparaît pas mais que HID fonctionne, l'interface HID peut être correcte tandis que le regroupement CDC est faux.

Les collisions d'adresses d'endpoints passent facilement inaperçues

Les adresses d'endpoints incluent la direction. L'endpoint 0x81 et 0x01 sont de directions différentes, mais deux endpoints IN avec la même adresse ne sont pas valides au sein de la même configuration. Les équipes firmware copient parfois des descripteurs d'endpoints entre interfaces et oublient de mettre à jour les adresses.

Symptômes :

  • une interface marche, une autre est muette
  • l'hôte envoie des transferts vers un endpoint inattendu
  • le pilote de classe charge mais l'application ne reçoit rien
  • STALL d'endpoint ou timeout après configuration
  • seule une fonction marche à la fois

La capture doit montrer côte à côte les descripteurs d'endpoints et le trafic de transfert ultérieur.

La liaison de pilote est aussi une preuve

L'hôte choisit les pilotes en fonction des descripteurs. Un périphérique qui se lie incorrectement peut avoir une preuve de descripteur qui explique pourquoi. Class, subclass, protocol, interface association, compatible IDs et descripteurs spécifiques à l'OS peuvent tous affecter la liaison.

Ne diagnostiquez pas la liaison de pilote uniquement à partir du Gestionnaire de périphériques ou des logs applicatifs. Comparez les requêtes spécifiques à la classe de l'hôte avec l'arborescence des descripteurs. Si les requêtes de classe attendues n'arrivent jamais, l'hôte n'a probablement pas lié le pilote attendu.

Où Bus Scope s'inscrit

Bus Scope doit aider les équipes firmware à inspecter les périphériques composites aux deux niveaux :

  • carte des descripteurs
  • preuves de transfert après la liaison du pilote

Une bonne session .bscope pour le débogage composite montre :

  • toutes les interfaces
  • regroupement IAD
  • affectations d'endpoints
  • requêtes spécifiques à la classe par interface
  • octets de descripteurs bruts
  • statut des transferts après configuration

Cela rend la conversation de support précise. Au lieu de « Windows n'aime pas notre périphérique composite », le rapport peut dire « l'interface 2 ne reçoit jamais les requêtes de classe CDC parce que le descripteur de regroupement ne correspond pas à la disposition d'interfaces déclarée ».

C'est le niveau de preuve dont les équipes firmware ont besoin.