Débogage bInterval d'endpoint interrupt USB

Les endpoints interrupt USB sont utilisés par les claviers, souris, manettes, capteurs, panneaux tactiles, scanners de codes-barres, onduleurs et beaucoup d'outils HID personnalisés. Les utilisateurs cherchent « USB bInterval », « HID polling rate », « USB interrupt endpoint latency », « missed input reports », « USB device 125Hz 250Hz 1000Hz » ou « bInterval full speed high speed » quand l'entrée semble retardée ou que les rapports arrivent au mauvais rythme.

Bus Scope est utile car le comportement de polling est défini par les descripteurs d'endpoint et le timing réel du bus. L'UI de l'OS ne montre souvent que « device connected » ; la capture peut montrer l'intervalle que l'hôte utilise réellement.

Ce que signifie bInterval

Un descripteur d'endpoint interrupt inclut bInterval. Cette valeur décrit l'intervalle de polling, mais l'interprétation dépend de la vitesse et du type d'endpoint.

Distinctions importantes :

• Les endpoints interrupt low-speed et full-speed utilisent des intervalles basés sur les frames en millisecondes.
• Les endpoints interrupt high-speed utilisent un encodage différent basé sur les microframes.
• L'ordonnancement du contrôleur hôte et la topologie du hub peuvent affecter le timing observé.
• Le timing de lecture applicative n'est pas le même que le polling du bus USB.

Si un ingénieur ne regarde que les callbacks applicatifs, il peut manquer le calendrier réel de l'endpoint.

Symptômes courants

Les problèmes d'intervalle de polling se manifestent par :

• Souris ou manette qui semble molle.
• Rapports d'entrée HID qui arrivent toutes les 8 ms au lieu de 1 ms.
• Périphérique annoncé à 1000 Hz mais qui se comporte comme du 125 Hz.
• Données de capteur en bursts.
• Scanner de codes-barres qui perd les scans rapides.
• Panneau tactile qui semble retardé après resume.
• Firmware qui envoie des rapports plus vite que l'hôte ne poll.
• Mode high-speed qui change le timing des rapports de façon inattendue.

Ces problèmes ressemblent souvent à des soucis de latence ou de réactivité, mais la preuve racine est dans le descripteur USB et le timing des paquets.

Interprétation full-speed vs high-speed

Le même bInterval numérique peut signifier un timing effectif différent selon la vitesse. Un endpoint HID full-speed avec bInterval=8 n'est pas le même modèle d'ordonnancement qu'un endpoint high-speed avec la même valeur en octets.

Le débogage doit capturer :

• Vitesse réellement négociée.
• Descripteur d'endpoint.
• Adresse de l'endpoint.
• Type de transfert.
• bInterval.
• Cadence des tokens IN ou des transferts observés.
• Timing des payloads de rapport.

Bus Scope doit montrer ensemble les valeurs du descripteur et le timing observé.

Surproduction firmware

Certains firmwares génèrent des rapports d'entrée plus vite que l'hôte ne poll. Ces rapports peuvent être écrasés, fusionnés ou perdus avant que l'hôte ne les voie jamais.

Symptômes :

• Les logs internes du périphérique montrent des événements.
• L'hôte reçoit moins de rapports.
• Les appuis rapides sur les boutons sont manqués.
• Le mouvement semble lissé ou retardé.
• Les rapports après un burst ne contiennent que le dernier état.

Ce n'est pas un problème de perte de paquets USB. C'est un problème de contrat de buffering firmware et de polling.

Le polling hôte n'est pas le taux de lecture applicatif

Une application peut lire toutes les 1 ms, mais l'hôte USB peut ne poller que toutes les 8 ms. Ou l'hôte peut poller à l'heure, mais la boucle d'événements applicative peut traiter les données plus tard.

La capture de paquets sépare :

• Intervalle de polling du bus.
• Timing de réponse du périphérique.
• Buffering du pilote hôte.
• Latence du callback applicatif.

Cette séparation est critique pour les cas de support de latence HID.

Erreurs de descripteur bInterval

Bugs de descripteurs fréquents :

• Annoncer accidentellement bInterval=10 au lieu de 1.
• Copier l'intervalle full-speed dans le descripteur high-speed incorrectement.
• Utiliser un intervalle dans les attentes du descripteur HID et un autre dans le descripteur d'endpoint.
• Les commentaires firmware annoncent 1000 Hz mais le descripteur dit plus lent.
• L'alternate setting change l'intervalle mais le firmware ne le gère pas.

L'octet dans le descripteur est le contrat sur lequel l'hôte ordonnance.

Checklist de débogage

Suivez ce flux :

1. Capturez l'énumération.
2. Identifiez les descripteurs d'endpoints interrupt.
3. Enregistrez la vitesse réelle du périphérique.
4. Décodez bInterval.
5. Mesurez la cadence IN d'interrupt observée.
6. Comparez avec le taux de polling attendu.
7. Déclenchez des événements d'entrée rapides.
8. Vérifiez si des rapports sont manqués ou fusionnés.
9. Comparez port direct vs hub.
10. Conservez ensemble descripteur et preuves de timing.

Diagnostic final

La latence d'interrupt USB n'est pas qu'un problème de performance applicative. Elle dépend du bInterval d'endpoint, du mode de vitesse, de l'ordonnancement hôte, de la génération de rapports et du buffering firmware.

Bus Scope aide à prouver si un périphérique HID ou interrupt est vraiment pollé au rythme voulu et si l'entrée manquée vient des réglages de descripteur, du buffering firmware ou du timing hôte/application.