Отладка USB String Descriptor и LANGID: serial number, производитель, имя продукта и проблемы привязки драйверов

Строковые USB-дескрипторы выглядят безобидно, но плохие строки могут сломать привязку драйверов, идентичность устройства, постоянство serial-порта, лабораторную автоматизацию, инструменты обновления прошивки и воркфлоу поддержки. Пользователи ищут «USB string descriptor failed», «LANGID descriptor», «USB serial number descriptor missing», «duplicate USB serial number», «USB product string wrong», «Windows shows unknown USB device name», когда устройство перечисляется, но идентичность нестабильна.

Bus Scope полезен, потому что сбои строковых дескрипторов случаются во время перечисления как управляющие передачи. Хост запрашивает поддерживаемые language ID, затем запрашивает строки manufacturer, product и serial number. Если какой-то шаг возвращает искажённые данные, ОС может продолжить, но сохранить плохую идентичность.

LANGID-дескриптор

Перед запросом конкретных строк хост может запросить string descriptor zero. Он возвращает поддерживаемые language ID.

Типичные доказательства:

GET_DESCRIPTOR String index 0
LANGID list returned
GET_DESCRIPTOR String index 1
GET_DESCRIPTOR String index 2
GET_DESCRIPTOR String index 3

Если string descriptor zero падает, последующие запросы строк могут вести себя несогласованно между хостами.

Строки manufacturer, product и serial

Типичные индексы строк:

• iManufacturer
• iProduct
• iSerialNumber

Эти поля ссылаются из device descriptor. Если устройство заявляет ненулевой индекс строки, но не может вернуть строку, поведение хоста может отличаться.

Симптомы:

• Устройство появляется как «Unknown Device».
• Имя продукта искажено.
• Serial-номер пустой.
• Windows создаёт новый COM-порт после каждого подключения.
• Правила udev в Linux надёжно не матчатся.
• Инструмент обновления прошивки не может опознать цель.
• Несколько устройств сливаются в одну идентичность.

Дублирующиеся serial-номера

Дублирующиеся USB serial-номера — серьёзная прод-проблема. Два физических устройства с одним VID, PID и serial-номером могут трактоваться как один экземпляр устройства.

Последствия:

• Загружаются неверные калибровочные данные.
• Тестовая станция пишет логи не на тот модуль.
• Назначение COM-порта меняется непредсказуемо.
• Лицензирование или provisioning привязывается к неверному железу.
• Полевая поддержка не различает устройства.

Пакетный захват может доказать, реально ли байты serial-дескриптора дублируются или слой отображения ОС скрывает более глубокую проблему.

Отсутствующий serial-номер

Некоторые устройства намеренно не имеют serial-номера. Это может быть приемлемо для простых периферийных устройств, но вызывает проблемы, когда важна стабильная идентичность.

Частые поисковые запросы:

• «USB device new COM port every time»
• «USB serial number missing»
• «Windows USB device instance path changes»
• «Linux udev match USB serial»

Если serial-номера нет, ОС может идентифицировать устройство по топологии порта, а не по аппаратной идентичности.

Искажённые UTF-16LE строки

USB-строки кодируются как Unicode. Баги прошивок:

• Неверная длина дескриптора.
• Нечётное число байт.
• Пропущенный тип дескриптора.
• Невалидные байты UTF-16LE.
• Рассогласование ожидаемого null-терминатора.
• Возврат ASCII-байт вместо USB-формата строки.
• Усечение длинных serial-номеров.

Часть хостов это терпит. Другие отвергают дескриптор или показывают corrupted текст.

Тайминги запросов строк и ретраи

Хосты могут запрашивать одну и ту же строку несколько раз с разными длинами. Устройство должно корректно обрабатывать и короткие пробные запросы, и полные.

Паттерны сбоев:

• Устройство возвращает правильные первые 2 байта, но падает на полном запросе.
• Прошивка считает, что wLength всегда равна длине дескриптора.
• Stall управляющей конечной точки на повторном запросе строки.
• Устройство возвращает другой serial-номер после reset.
• Загрузчик и прикладная прошивка сообщают разную идентичность.

Это часто встречается в воркфлоу обновления прошивки.

Влияние на привязку драйверов

Выбор драйвера обычно зависит от VID/PID/класса, но строковые дескрипторы влияют на видимую идентичность и иногда на вендорные инструменты. Составные устройства, CDC serial-устройства, HID-инструменты и DFU-загрузчики часто опираются на строки для поддержки и автоматизации.

Если в тикете написано «wrong USB device name», не отмахивайтесь как от косметики. Это может быть признак corruption дескриптора или путаницы состояний прошивки.

Чек-лист отладки

Используйте такой процесс:

1. Захватите перечисление с момента подключения.
2. Изучите string indexes в device descriptor.
3. Проверьте string descriptor zero на LANGID.
4. Декодируйте manufacturer-строку.
5. Декодируйте product-строку.
6. Декодируйте serial-номер.
7. Сравните два физических устройства.
8. Сравните загрузчик и прикладную прошивку.
9. Проверьте поведение после reset и переподключения.
10. Сохраните сырые байты дескрипторов для фиксов прошивки.

Итоговый диагноз

Проблемы USB string descriptor и LANGID влияют на идентичность устройства, постоянство serial, производственные тесты, полевую поддержку и воркфлоу драйверов. Ключевое доказательство — не метка ОС, а реальные управляющие передачи дескрипторов.

Bus Scope помогает показать LANGID, manufacturer, product, serial number, искажённые строки, дублирующиеся serial-номера и повторы перечисления в одном диагностическом виде.