Тайм-аут вендорного USB Control Request: отладка firmware-команд, bmRequestType и endpoint 0

Вендорные USB Control Request часты в инструментах прошивки, калибровочных утилитах, factory-тестовом ПО, загрузчиках, отладочных режимах и кастомных устройствах. Когда они ломаются, приложения часто сообщают только «control transfer timeout», «vendor request failed», «device not responding» или LIBUSB_ERROR_TIMEOUT. Пользователи ищут «USB vendor request timeout», «bmRequestType debugging», «control transfer endpoint zero timeout», «vendor-specific USB command failed», потому что сбой в приватном протоколе, который ОС не может объяснить.

Bus Scope полезен, потому что каждый вендорный Control Request всё равно имеет стандартный setup-пакет. Даже если значение команды приватное, структура передачи видна.

Поля setup-пакета

Control request включает:

• bmRequestType
• bRequest
• wValue
• wIndex
• wLength

Для вендорных запросов bmRequestType задаёт вендорный тип и направление. bRequest, wValue и wIndex определяются прошивкой устройства.

Если направление или длина неверны, устройство может поставить stall или тайм-аутить.

Тайм-аут vs STALL

STALL — устройство явно отвергло запрос. Тайм-аут — хост не получил завершения вовремя.

Тайм-аут может означать:

• Прошивка зависла при обработке команды.
• Устройство сбросилось во время запроса.
• Рассогласование направления.
• Хост ждал данные, а устройство ничего не прислало.
• Устройство ждало OUT-данных, а хост запросил IN.
• Команда валидна только в другом состоянии.
• Flash erase или сенсорная операция заняла слишком долго.

Трасса должна показать, была ли data-стадия и исчезло ли устройство после этого.

Команды загрузчика и обновления прошивки

Вендорные запросы часто триггерят вход в загрузчик, flash erase, запись прошивки, reset или поллинг статуса. Эти команды могут законно занимать время, но тайм-аут хоста должен соответствовать ожидаемому поведению.

Если запрос всегда тайм-аутит перед переподключением, устройство, возможно, действительно сбрасывается успешно. Если тайм-аутит и никогда не пере-нумеруется — прошивка могла зависнуть.

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

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

1. Захватите до посылки вендорной команды.
2. Декодируйте поля setup-пакета.
3. Подтвердите направление, совпадающее с ожидаемой data-стадией.
4. Проверьте wLength.
5. Ищите байты data-стадии.
6. Ищите STALL, тайм-аут, reset или отключение.
7. Проверьте, пере-нумеруется ли устройство в другом режиме.
8. Сравните последовательность команд с известным рабочим инструментом.
9. Увеличивайте тайм-аут только после доказательства, что команда реально занимает больше.
10. Сохраните последовательность вендорных запросов до и после сбоя.

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

Тайм-ауты вендорных Control Request — сбои приватного протокола, но USB-доказательства всё равно видны. Setup-пакет, направление, длина, тайминг, поведение reset и ответ endpoint 0 показывают, виновата ли форма запроса хоста или состояние прошивки устройства.

Bus Scope помогает превратить сбой приватной firmware-команды в проверяемые USB-доказательства.