Débogage série USB CDC ACM : line coding, état des lignes de contrôle et données manquantes

Les périphériques USB CDC ACM sont utilisés pour les ports série virtuels, consoles de périphérique, outils firmware, télémétrie, moyens de test et diagnostics embarqués. Côté application, c'est simple: "ouvrir un port COM ou /dev/ttyACM*, régler un baud rate, lire et écrire des octets. En dessous, hôte et périphérique échangent toujours des requêtes USB spécifiques à la classe et des transferts bulk." Quand un périphérique CDC s'énumère mais qu'aucune donnée ne circule, la capture peut dire si le problème vient du descripteur, du line coding, de l'état des lignes de contrôle, du trafic d'endpoint ou du buffering firmware.

CDC ACM a des interfaces de contrôle et de données

Un périphérique CDC ACM typique expose une interface de communication et une interface de données. L'hôte peut envoyer des requêtes spécifiques à la classe avant que le transfert de données ne commence.

Preuves importantes :

• descripteur d'interface de communication
• descripteur d'interface de données
• descripteurs fonctionnels CDC
• endpoint de notification
• endpoint bulk IN
• endpoint bulk OUT
• SET_LINE_CODING
• GET_LINE_CODING
• SET_CONTROL_LINE_STATE

Si ces requêtes n'arrivent jamais, l'hôte n'a peut-être pas lié le pilote CDC attendu.

Le baud rate est souvent un signal, pas un UART physique

Pour beaucoup de périphériques USB CDC, le baud rate n'a pas la même signification physique que pour un UART. Mais l'hôte envoie quand même le line coding. Le firmware peut s'en servir pour configurer un pont, l'ignorer ou le valider.

Questions à capturer :

• l'hôte a-t-il envoyé SET_LINE_CODING ?
• quel baud rate, parité, bits de stop et bits de données ont été demandés ?
• le firmware a-t-il accepté la requête ?
• l'hôte a-t-il asserté DTR ou RTS avec SET_CONTROL_LINE_STATE ?
• le firmware attend-il DTR avant d'envoyer ?

Beaucoup de problèmes « pas de sortie série » sont en réalité « le firmware attend DTR et l'hôte ne l'a jamais asserté » ou « l'application a ouvert le port mais ne l'a pas configuré comme attendu ».

Les endpoints bulk prouvent le mouvement des données

Après le setup, les données CDC passent généralement par les endpoints bulk. Si les écritures de l'hôte apparaissent sur bulk OUT mais qu'aucune réponse bulk IN ne suit, le firmware n'émet peut-être pas. Si des données bulk IN apparaissent mais que l'application ne les affiche pas, le problème peut être dans le comportement applicatif de l'hôte.

Inspectez :

• direction de l'endpoint
• longueurs de transfert
• comportement NAK/timeout répété
• octets de charge utile réels
• statut des transferts
• ordonnancement par rapport aux requêtes d'état de ligne

C'est ainsi qu'une capture USB devient plus utile qu'une capture d'écran de terminal.

Où Bus Scope s'inscrit

Bus Scope doit aider les équipes firmware à garder ensemble descripteurs, requêtes de classe et données brutes d'endpoint dans une même session. Pour le débogage CDC ACM, il doit répondre à :

• l'hôte a-t-il lié CDC ?
• quel line coding a-t-il envoyé ?
• DTR/RTS ont-ils changé ?
• bulk OUT a-t-il porté des commandes ?
• bulk IN a-t-il porté des réponses ?
• le problème est-il survenu avant ou après le début du trafic de style série ?

Pour des recherches comme « USB CDC ACM no data », « virtual COM port no output » ou « SET_CONTROL_LINE_STATE DTR », la preuve n'est pas dans le terminal seul. Elle est dans les requêtes de classe USB et les transferts d'endpoint.