Отладка USB CDC ACM Serial: line coding, control line state и пропавшие данные

USB CDC ACM-устройства используются для виртуальных serial-портов, консолей устройств, инструментов прошивки, телеметрии, тестовых стендов и встроенной диагностики. Со стороны приложения всё выглядит просто: "открыл COM-порт или /dev/ttyACM*, задал baud rate, читал и писал байты. Под капотом хост и устройство всё равно обмениваются класс-управляющими USB-запросами и bulk-передачами." Когда CDC-устройство перечисляется, но данные не идут, захват покажет, в чём проблема: "layout дескрипторов, line coding, control line state, трафик конечных точек или буферизация прошивки."

У CDC ACM есть интерфейсы Control и Data

Типичное CDC ACM-устройство выставляет коммуникационный интерфейс и интерфейс данных. Хост может слать класс-управляющие запросы до начала обмена данными.

Важные доказательства:

• communication interface descriptor
• data interface descriptor
• CDC functional descriptors
• notification-конечная точка
• bulk IN-конечная точка
• bulk OUT-конечная точка
• SET_LINE_CODING
• GET_LINE_CODING
• SET_CONTROL_LINE_STATE

Если эти запросы не приходят, возможно, хост не привязал ожидаемый CDC-драйвер.

Baud rate — часто сигнал, а не физический UART

Для многих USB CDC-устройств baud rate не имеет физического смысла в том же смысле, что для UART. Но хост всё равно шлёт line coding. Прошивка может использовать его, чтобы сконфигурировать мост, проигнорировать или валидировать.

Вопросы к захвату:

• послал ли хост SET_LINE_CODING?
• какой baud rate, parity, stop bits и data bits были запрошены?
• приняла ли прошивка запрос?
• установил ли хост DTR или RTS через SET_CONTROL_LINE_STATE?
• ждёт ли прошивка DTR перед отправкой?

Многие проблемы «нет serial-вывода» на самом деле «прошивка ждёт DTR, а хост его никогда не установил» или «приложение открыло порт, но не сконфигурировало как ожидалось».

Bulk-конечные точки доказывают движение данных

После настройки CDC-данные обычно идут через bulk-конечные точки. Если записи хоста видны на bulk OUT, но bulk IN-ответа нет, прошивка, возможно, не отправляет. Если данные на bulk IN идут, но приложение их не отображает, проблема может быть на стороне приложения.

Изучите:

• направление конечной точки
• длины передач
• повторяющееся NAK/timeout-поведение
• реальные байты полезной нагрузки
• статус передач
• порядок относительно line-state запросов

Вот как USB-захват становится полезнее терминального скриншота.

Место Bus Scope

Bus Scope должен помогать командам прошивок держать дескрипторы, класс-запросы и сырые данные по конечным точкам в одном сеансе. Для отладки CDC ACM он должен отвечать:

• привязал ли хост CDC?
• какой line coding он послал?
• менялся ли DTR/RTS?
• нёс ли bulk OUT команды?
• нёс ли bulk IN ответы?
• случилась ли проблема до или после начала serial-трафика?

Для запросов вроде «USB CDC ACM no data», «virtual COM port no output», «SET_CONTROL_LINE_STATE DTR» доказательства не только в терминале. Они в USB класс-запросах и передачах по конечным точкам.