2026-06-02

Décalage de taille de paquet max d'endpoint USB

Comment déboguer les décalages de taille de paquet max d'endpoint USB, erreurs de descripteur wMaxPacketSize, paquets courts, stalls de transfert bulk, différences high-speed vs full-speed et bugs de buffer firmware.

Le wMaxPacketSize d'un endpoint USB ressemble à un petit champ de descripteur, mais une valeur erronée peut casser les transferts bulk, les rapports interrupt, le fonctionnement high-speed, le buffering firmware et les hypothèses du pilote hôte. Les utilisateurs cherchent « USB wMaxPacketSize mismatch », « USB short packet problem », « bulk transfer stops at 64 bytes », « USB endpoint packet size high speed full speed » ou « USB descriptor max packet size bug » quand les transferts échouent seulement à certaines tailles ou vitesses.

Bus Scope est utile car la défaillance n'est visible que quand descripteurs et paquets de transfert sont comparés ensemble. Le descripteur peut annoncer une taille de paquet tandis que le firmware, le code hôte ou le hardware de l'endpoint se comporte comme une autre taille.

Ce que contrôle wMaxPacketSize

Chaque descripteur d'endpoint inclut wMaxPacketSize. Il indique à l'hôte la taille de payload max pour cet endpoint. Les valeurs typiques dépendent de la vitesse et du type d'endpoint.

Exemples :

Un endpoint bulk full-speed utilise souvent 64 octets.
Un endpoint bulk high-speed utilise souvent 512 octets.
Les endpoints interrupt varient selon la vitesse et l'intervalle.
Les endpoints isochrones utilisent des tailles de paquet spécifiques à la bande passante.

Si le firmware configure des buffers d'endpoint pour 64 octets mais en annonce 512, l'hôte peut envoyer des transferts que le périphérique ne peut pas gérer correctement.

Symptômes courants

Les bugs de taille de paquet max d'endpoint peuvent apparaître comme :

Transfert bulk qui réussit pour les petits messages mais échoue pour les gros.
Périphérique qui marche en full-speed mais échoue en high-speed.
Transfert qui s'arrête après exactement 64 octets.
Hôte qui attend indéfiniment un paquet court.
Firmware qui reçoit des données splittées de façon inattendue.
Périphérique qui stall les transferts OUT.
Transferts IN qui renvoient des données tronquées.
Pilote qui signale un timeout alors qu'il y a du trafic.
Périphérique composite qui marche sur une interface mais pas une autre.

Le compte exact d'octets est souvent l'indice.

Comportement de paquet court

Les transferts bulk USB utilisent souvent des paquets courts pour indiquer la fin d'un transfert quand la longueur demandée est plus grande que les données réelles. Si le périphérique renvoie exactement un multiple de la taille de paquet max, l'hôte peut attendre plus de données sauf si le protocole définit la longueur séparément ou envoie un paquet de longueur zéro.

Par exemple :

taille de paquet max : 64
longueur de payload : 128
paquets : 64 + 64
condition de fin : ambiguë sauf si la longueur est connue ou ZLP envoyé

C'est pourquoi « USB short packet » et « USB zero length packet » sont des termes de recherche forts. Un périphérique peut passer des tests simples puis se bloquer quand la longueur de payload tombe exactement sur une frontière de paquet.

Décalage high-speed vs full-speed

Certains périphériques se comportent correctement en full-speed mais échouent en high-speed. Causes possibles :

Le descripteur high-speed annonce 512 octets.
Le buffer firmware reste à 64 octets.
L'alignement DMA change en high-speed.
Le FIFO d'endpoint est trop petit.
Le pilote hôte suppose une packetization high-speed.
Le Device Descriptor diffère entre modes de vitesse.

Bus Scope doit aider à comparer la vitesse d'énumération, les valeurs de descripteurs d'endpoint et le chunking réel des transferts.

Erreurs de copier-coller de descripteurs

Les équipes firmware copient souvent des descripteurs d'endpoint entre interfaces ou modes. Cela peut créer des bugs subtils :

Endpoint interrupt qui annonce une taille de type bulk.
Taille d'endpoint OUT qui diffère de IN de façon inattendue.
Alternate setting avec taille différente mais firmware qui ne reconfigure pas l'endpoint.
Arborescences de descripteurs full-speed et high-speed en désaccord.
Descripteurs compagnons qui ne correspondent pas au débit attendu.

La bonne vue diagnostique lie l'adresse de l'endpoint à son descripteur et à chaque transfert sur cet endpoint.

Bugs de buffer firmware

Même quand le descripteur est correct, le firmware peut traiter les données incorrectement :

Suppose qu'un paquet USB égale un message applicatif.
Ne gère pas les messages splittés.
Laisse tomber les paquets de longueur zéro.
Traite un paquet court comme une erreur.
Écrase le buffer de réception après le premier paquet.
Échoue quand la longueur de transfert égale la taille de paquet max.
Ne flush pas l'endpoint IN après le paquet court final.

Ces bugs sont fréquents dans les périphériques vendor et les bootloaders car le protocole est généralement personnalisé.

Hypothèses du pilote hôte

Le code hôte peut aussi être faux. Il peut :

Demander un buffer trop petit.
S'attendre à ce qu'un read corresponde à un message du périphérique.
Ignorer la terminaison par paquet court.
Utiliser un timeout au lieu du framing par longueur de protocole.
Envoyer une commande plus grande que le buffer firmware.
Oublier le comportement de paquet de longueur zéro.

Quand les deux côtés sont personnalisés, la trace de paquets devient le contrat.

Preuves à collecter

Pour un diagnostic de taille de paquet max, collectez :

Vitesse du périphérique.
Descripteur d'endpoint.
Adresse et direction de l'endpoint.
wMaxPacketSize.
Taille de transfert demandée par l'hôte.
Tailles de paquets réellement observées.
Présence de paquet court ou de paquet de longueur zéro.
STALL, NAK, timeout ou reset après le transfert.
Différence entre énumération full-speed et high-speed.
Logs firmware si disponibles.

Les meilleurs rapports incluent les comptes exacts d'octets. Les moteurs de recherche matchent aussi bien ces détails pratiques.

Checklist de débogage

Suivez ce processus :

Identifiez le descripteur d'endpoint.
Enregistrez wMaxPacketSize.
Comparez le mode de vitesse.
Envoyez des payloads en dessous, à égalité et au-dessus de la taille de paquet max.
Testez les multiples exacts de la taille de paquet max.
Cherchez un paquet court ou de longueur zéro.
Vérifiez si l'hôte attend après le paquet final.
Comparez le comportement IN et OUT.
Vérifiez les changements d'alternate setting.
Conservez la séquence de transfert défaillante.

Diagnostic final

Les bugs de taille de paquet max d'endpoint USB sont des problèmes de descripteur, de transfert et de contrat firmware. La preuve utile est le wMaxPacketSize annoncé, la packetization réelle, le comportement de paquet court, la gestion du paquet de longueur zéro, le mode de vitesse et les défaillances spécifiques à l'endpoint.

Bus Scope aide les ingénieurs à prouver si le bug est dans le descripteur, la gestion des buffers firmware, les hypothèses du pilote hôte ou le framing du transfert.

Test du contrat USB pour « Décalage de taille de paquet max d'endpoint USB »

La réponse directe est qu’un STALL, timeout ou reset n’explique pas seul la cause. Prouvez d’abord que le fournisseur voit le bon périphérique, puis lisez le contrat du transfer : type, direction, recipient, wValue, wIndex, longueur annoncée et réelle, status et état avant/après. Pour « Décalage de taille de paquet max d'endpoint USB », reliez la conclusion à la première transaction différente d’un cas nominal.

Limite	Comparaison	Décision
Plateforme	fournisseur, droits, Root Hub ou usbmon/XHC20	Les records viennent-ils de la bonne connexion ?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	L’hôte envoie-t-il la requête prévue ?
Data	direction, longueur et bytes conservés	Le payload respecte-t-il le contrat ?
Status	ACK, STALL, timeout ou cancellation	Où finit réellement la transaction ?
État	configuration, interface, alternate setting, endpoint halt	Le périphérique était-il prêt ?

Commencez avant reset et énumération et gardez descriptors, SET_CONFIGURATION, SET_INTERFACE et la commande avant défaut. Un filtre endpoint étroit peut masquer le control transfer décisif. Exécutez une seule action USB documentée par essai et ne changez que firmware, driver, port, câble, commande ou timing.

Comment rédiger une réponse réutilisable ?

Nommez requête, champs setup, réponse et contexte précédent, puis un test à variable unique. Des bytes non retenus ne prouvent pas packet loss. La proximité entre command et reset établit une corrélation, pas la cause sans répétition ou transition d’état.

Quand la comparaison est-elle valide ?

Gardez VID/PID, firmware, speed, topologie, fournisseur, filtre et trigger. Comparez les phases USB sémantiques, pas les frame numbers entre usbmon et USBPcap. Notez début, fin, version, OS, connexion et checksum. Consultez le dépannage Bus Scope.

Les propriétaires Semrush restent distincts : free USB analyzer sur la page produit, best USB protocol analyzer dans la comparaison et USB descriptor viewer dans le guide descriptor. Aucun volume ou KD n’est inventé pour cette page de support.

Réponse directe et limite d’acceptation

La réponse courte à « Décalage de taille de paquet max d'endpoint USB » est la suivante : Comment déboguer les décalages de taille de paquet max d'endpoint USB, erreurs de descripteur wMaxPacketSize, paquets courts, stalls de transfert bulk, différences high-speed vs full-speed et bugs de buffer firmware. Considérez cette phrase comme un résultat à vérifier, et non comme une promesse valable pour toute entrée, tout appareil, tout projet ou tout environnement. Un résultat complet consigne l’état initial, l’action exacte, la sortie visible et la condition qui prouve la fin de la tâche dans Bus Scope.

Procédure fondée sur les preuves

Commencez par un cas petit et répétable avant de modifier un projet complet. Notez version de l’application, système, identité de l’entrée ou de l’appareil, réglages pertinents et résultat attendu. Exécutez une action volontaire, conservez la première transition inattendue et comparez-la à un cas nominal si possible. Plusieurs changements simultanés masquent la condition qui a créé ou corrigé le problème.

Point de contrôle 1 : Décalage de taille de paquet max d'endpoint USB

Ne fermez « Décalage de taille de paquet max d'endpoint USB » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 2 : Comment déboguer les décalages de taille de paquet max d'endpoint USB, erreurs de descript

Pour « Comment déboguer les décalages de taille de paquet max d'endpoint USB, erreurs de descripteur wMaxPacketSize, paquets courts, stalls de transfert bulk », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 3 : Ce que contrôle wMaxPacketSize

Ne fermez « Ce que contrôle wMaxPacketSize » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 4 : Symptômes courants

Pour « Symptômes courants », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 5 : Comportement de paquet court

Ne fermez « Comportement de paquet court » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 6 : Décalage high-speed vs full-speed

Pour « Décalage high-speed vs full-speed », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 7 : Erreurs de copier-coller de descripteurs

Ne fermez « Erreurs de copier-coller de descripteurs » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 8 : Bugs de buffer firmware

Pour « Bugs de buffer firmware », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Point de contrôle 9 : Hypothèses du pilote hôte

Ne fermez « Hypothèses du pilote hôte » que lorsque le résultat enregistré, exporté ou rouvert correspond encore à l’état observé. Le retour temporaire de l’interface aide, mais une preuve durable est plus forte. Consignez toute limite restante pour la suite.

Point de contrôle 10 : Preuves à collecter

Pour « Preuves à collecter », séparez une décision du produit d’une limite du système, du matériel, du fichier source, des droits ou du processus. Confirmez la couche qui fournit la preuve avant d’attribuer une cause. Un symptôme voisin ne devient ainsi pas une cause racine prétendument prouvée.

Matrice d’acceptation

Point	Preuve à conserver	Critère de réussite
Décalage de taille de paquet max d'endpoint USB	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comment déboguer les décalages de taille de paquet max d'endpoint USB, erreurs de descripteur wMaxPacketSize, paquets co	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Ce que contrôle wMaxPacketSize	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Symptômes courants	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Comportement de paquet court	État initial, une action et état obtenu	Une seconde personne reproduit le résultat
Décalage high-speed vs full-speed	État initial, une action et état obtenu	Une seconde personne reproduit le résultat

Isolation, reprise et transmission

Arrêtez-vous à la première limite en échec. Conservez source, projet, session ou capture, dupliquez avant toute modification destructive et changez une variable par essai. Rejouer un flux entier après plusieurs changements peut modifier le résultat sans expliquer pourquoi.

Distinguez absence de preuve et preuve d’absence. Une vue vide peut signaler mauvaise entrée, portée, filtre, permission, appareil, période ou état du projet. Vérifiez acquisition ou import avant d’interpréter décodeur, éditeur, rapport ou export.

Avant transmission, rouvrez l’artefact durable et inspectez début, point de décision et fin. Notez version, plateforme, configuration, attente, observation et reproduction minimale. Retirez ou masquez les données sensibles et confirmez l’autorisation du destinataire.

Questions et réponses

Quelle est la manière fiable la plus rapide de commencer ?

Utilisez le plus petit cas représentatif, écrivez le résultat attendu et ne changez qu’une variable. Validez le parcours de base avant d’ajouter filtres, effets, modifications, automatisation ou grande source.

Quelles preuves faut-il conserver ?

Gardez identité de l’entrée, version, plateforme, réglages, action exacte, première transition inattendue et sortie finale. Fermez puis rouvrez projet, session, rapport ou export avant de le considérer durable.

Quand faut-il répéter la procédure ?

Répétez-la après un changement pertinent d’application, système, pilote, firmware, modèle, source ou processus. Conservez le cas accepté précédent comme référence non modifiée.

Quand le résultat est-il transmissible ?

Lorsqu’une seconde personne autorisée identifie l’entrée, répète l’action, obtient le même résultat, comprend les limites et ouvre l’artefact sans état local non documenté.

Guides associés

Ces pages dans la même langue couvrent les étapes voisines sans changer le propriétaire canonique du sujet :