Débogage USB CDC ACM DTR et RTS : SetControlLineState, ouvertures de port série, reset bootloader et données manquantes

Les périphériques USB CDC ACM ressemblent à des ports série, mais beaucoup de bugs « port série » sont en réalité des bugs de contrôle de classe USB. Les utilisateurs cherchent « CDC ACM DTR RTS », « SetControlLineState USB », « USB serial no data until DTR », « Arduino resets when serial port opens », « USB CDC bootloader reset » ou « COM port opens but device does not respond » quand le port existe mais que le comportement est faux.

Bus Scope est utile car DTR et RTS ne sont pas de simples flags applicatifs magiques. L'hôte envoie des requêtes de contrôle spécifiques à la classe, et le firmware réagit à ces requêtes.

Ce que fait SetControlLineState

CDC ACM utilise une requête de classe communément appelée SetControlLineState. Elle communique l'état des lignes de contrôle telles que :

• DTR : Data Terminal Ready
• RTS : Request To Send

Beaucoup de périphériques utilisent ces bits au-delà du simple comportement modem traditionnel. Le firmware peut commencer à streamer uniquement après l'assertion de DTR, entrer en bootloader quand DTR bascule, ou utiliser RTS pour la sémantique de contrôle de flux.

Symptômes courants

Les problèmes de lignes de contrôle se manifestent par :

• le port COM s'ouvre mais aucune donnée n'arrive
• le périphérique commence à émettre seulement après la connexion du programme terminal
• le firmware reset à l'ouverture d'un moniteur série
• le bootloader apparaît après ouverture/fermeture du port
• les données s'arrêtent quand DTR retombe
• l'option de contrôle de flux RTS/CTS change le comportement
• outil Linux marche mais outil Windows non
• script Python qui se comporte différemment d'un émulateur de terminal

Ces formulations correspondent aux symptômes que les ingénieurs décrivent quand ils essaient de reproduire la défaillance.

Comportement d'ouverture du port série

Différentes applications hôtes positionnent DTR et RTS différemment à l'ouverture du port.

Exemples :

• un émulateur de terminal assert DTR immédiatement
• un script ouvre le port mais laisse DTR à false
• un outil de mise à jour firmware toggle DTR comme signal de reset
• le pilote positionne RTS selon les réglages de contrôle de flux
• l'application ferme le port et lâche DTR de façon inattendue

La trace de paquets peut montrer la séquence réelle des requêtes de contrôle au lieu de s'appuyer sur les hypothèses applicatives.

Motifs de reset bootloader

Beaucoup de cartes de développement utilisent les transitions DTR ou RTS pour reset en mode bootloader. C'est pratique pour l'upload du firmware, mais surprenant dans les outils de production.

Motifs de défaillance :

• le périphérique reset à chaque ouverture d'un viewer de logs
• l'upload du firmware marche mais la connexion série normale échoue
• le périphérique apparaît sous une identité USB, reset, puis se ré-énumère en bootloader
• le numéro de série ou la chaîne produit change après reset
• l'application perd le handle du port

Bus Scope doit conserver la requête de contrôle et la séquence de ré-énumération.

Pas de données tant que DTR n'est pas asserté

Certains firmwares attendent volontairement DTR avant d'envoyer des données. Cela peut faire apparaître un outil comme cassé alors qu'un autre fonctionne.

Preuves :

• l'hôte ouvre les endpoints bulk ou interrupt
• aucune donnée IN n'est envoyée
• l'hôte envoie SetControlLineState avec DTR à true
• le périphérique commence à transmettre

Ce n'est pas un problème de câble et pas nécessairement un bug de pilote. C'est une politique firmware.

Confusion RTS et contrôle de flux

RTS peut servir au contrôle de flux matériel, mais beaucoup de périphériques USB CDC n'ont pas de vraies lignes modem. Le firmware peut quand même exposer l'état RTS à la logique applicative.

Questions :

• l'hôte positionne-t-il RTS ?
• le périphérique requiert-il RTS avant d'émettre ?
• activer le contrôle de flux matériel dans le terminal change-t-il les bits de la requête ?
• le firmware ignore-t-il RTS alors que la documentation prétend le contraire ?
• RTS est-il utilisé comme signal bootloader ou sélecteur de mode ?

Les preuves de paquets évitent de deviner.

Checklist de débogage

Suivez ce processus :

1. Capturez l'énumération.
2. Ouvrez le port série avec l'application défaillante.
3. Enregistrez les requêtes spécifiques à la classe CDC.
4. Trouvez SetControlLineState.
5. Décodez les bits DTR et RTS.
6. Comparez avec un programme terminal fonctionnel.
7. Vérifiez si les données démarrent après DTR.
8. Vérifiez si un reset ou une ré-énumération suit un toggle.
9. Comparez les outils Windows et Linux.
10. Conservez ensemble les requêtes de contrôle et les premiers paquets de données.

Diagnostic final

Les problèmes USB CDC ACM DTR et RTS sont des problèmes d'ordonnancement de contrôle de classe. Le port peut exister et les pilotes peuvent se lier correctement alors que le firmware attend un état de ligne de contrôle que l'application n'envoie jamais.

Bus Scope aide à montrer SetControlLineState, DTR, RTS, le comportement d'ouverture série, les resets bootloader et les causes de données manquantes au niveau du protocole USB.