Débogage des descripteurs string USB et LANGID

Les descripteurs string USB semblent inoffensifs, mais de mauvais strings peuvent casser la liaison de pilote, l'identité du périphérique, la persistance du port série, l'automatisation de laboratoire, les outils de mise à jour firmware et les flux de support. Les utilisateurs cherchent « USB string descriptor failed », « LANGID descriptor », « USB serial number descriptor missing », « duplicate USB serial number », « USB product string wrong » ou « Windows shows unknown USB device name » quand le périphérique s'énumère mais que l'identité est instable.

Bus Scope est utile car les échecs de descripteurs string surviennent pendant l'énumération comme transferts de contrôle. L'hôte demande les language IDs supportés, puis les strings manufacturer, product et numéro de série. Si une étape renvoie des données mal formées, l'OS peut continuer mais stocker une mauvaise identité.

Descripteur LANGID

Avant de demander des strings spécifiques, l'hôte peut demander le descripteur string zéro. Celui-ci renvoie les language IDs supportés.

Preuve typique :

GET_DESCRIPTOR String index 0
LANGID list retournée
GET_DESCRIPTOR String index 1
GET_DESCRIPTOR String index 2
GET_DESCRIPTOR String index 3

Si le descripteur string zéro échoue, les requêtes de string ultérieures peuvent se comporter de façon incohérente entre hôtes.

Strings manufacturer, product et série

Index de string courants :

• iManufacturer
• iProduct
• iSerialNumber

Ces champs sont référencés depuis le Device Descriptor. Si le périphérique annonce un index de string non nul mais échoue à renvoyer le string, le comportement de l'hôte peut varier.

Symptômes :

• Le périphérique apparaît comme « Unknown Device ».
• Le nom produit est brouillé.
• Le numéro de série est vide.
• Windows crée un nouveau port COM à chaque branchement.
• Les règles udev Linux ne matchent pas de façon fiable.
• L'outil de mise à jour firmware ne peut pas identifier la cible.
• Plusieurs unités se collapsent en une seule identité.

Numéros de série dupliqués

Les numéros de série USB dupliqués sont un sérieux problème de production. Deux périphériques physiques avec le même VID, PID et numéro de série peuvent être traités comme la même instance de périphérique.

Conséquences :

• Mauvaises données de calibration chargées.
• La station de test écrit des logs vers la mauvaise unité.
• L'attribution de port COM change de façon imprévisible.
• Le licensing ou provisioning se lie au mauvais hardware.
• Le support terrain ne peut pas distinguer les périphériques.

La capture de paquets peut prouver si les octets du descripteur série sont réellement dupliqués ou si la couche d'affichage OS cache un problème plus profond.

Numéro de série manquant

Certains périphériques omettent volontairement un numéro de série. C'est acceptable pour des périphériques simples, mais cela pose problème quand une identité stable compte.

Termes de recherche fréquents :

• « USB device new COM port every time »
• « USB serial number missing »
• « Windows USB device instance path changes »
• « Linux udev match USB serial »

Si le numéro de série est manquant, l'OS peut identifier le périphérique par la topologie de port plutôt que par l'identité hardware.

Strings UTF-16LE mal formés

Les strings USB sont encodés en Unicode. Bugs firmware :

• Mauvaise longueur de descripteur.
• Compte d'octets impair.
• Type de descripteur manquant.
• Octets UTF-16LE invalides.
• Attente de terminaison null non satisfaite.
• Renvoi d'octets ASCII au lieu du format string USB.
• Troncature de longs numéros de série.

Certains hôtes le tolèrent. D'autres rejettent le descripteur ou affichent du texte corrompu.

Timing de requête string et retries

Les hôtes peuvent demander le même string plusieurs fois avec des longueurs différentes. Un périphérique doit gérer à la fois les requêtes courtes de probe et les requêtes en pleine longueur.

Motifs de défaillance :

• Le périphérique renvoie les 2 premiers octets corrects mais échoue la requête complète.
• Le firmware suppose que wLength égale toujours la longueur du descripteur.
• L'endpoint de contrôle stall sur les requêtes string répétées.
• Le périphérique renvoie un numéro de série différent après reset.
• Le bootloader et le firmware applicatif rapportent des identités différentes.

C'est fréquent dans les flux de mise à jour firmware.

Impact sur la liaison de pilote

La sélection du pilote dépend généralement de VID/PID/class, mais les descripteurs string affectent l'identité visible par l'utilisateur et parfois les outils vendor. Les périphériques composites, CDC série, HID et DFU bootloaders s'appuient souvent sur les strings pour le support et l'automatisation.

Si un ticket de support dit « wrong USB device name », ne le balayez pas comme cosmétique. Il peut indiquer une corruption de descripteur ou une confusion d'état firmware.

Checklist de débogage

Suivez ce processus :

1. Capturez l'énumération depuis le branchement.
2. Inspectez les index de string du Device Descriptor.
3. Vérifiez le descripteur string zéro pour le LANGID.
4. Décodez le string manufacturer.
5. Décodez le string product.
6. Décodez le string numéro de série.
7. Comparez deux unités physiques.
8. Comparez le bootloader et le firmware applicatif.
9. Vérifiez le comportement après reset et rebranchement.
10. Conservez les octets de descripteurs bruts pour les correctifs firmware.

Diagnostic final

Les problèmes de descripteurs string USB et LANGID affectent l'identité du périphérique, la persistance série, les tests de fabrication, le support terrain et les flux de pilote. La preuve clé n'est pas le label de l'OS mais les transferts de contrôle de descripteurs réels.

Bus Scope aide à montrer LANGID, manufacturer, product, numéro de série, strings mal formés, séries dupliquées et retries d'énumération dans une vue diagnostique unique.