Отладка status-стадии управляющей USB-передачи: ZLP, endpoint 0, последовательность SETUP/DATA/STATUS

Управляющие USB-передачи выглядят просто, пока устройство не падает в status-стадии. Пользователи ищут «USB control transfer status stage», «zero length packet USB», «endpoint zero stall», «SETUP DATA STATUS USB», «control transfer timeout», «vendor request fails», когда дескрипторы работают, но одна команда ставит stall или тайм-аутит.

Bus Scope полезен тем, что для отладки управляющих передач нужно видеть все стадии вместе. Одного setup-пакета мало. Data- и status-стадия доказывают, что хост и устройство завершили транзакцию.

Стадии управляющей передачи

Управляющая передача обычно состоит из:

• Стадии SETUP.
• Необязательной DATA-стадии.
• STATUS-стадии.

В status-стадии часто идёт пакет нулевой длины в направлении, противоположном data-стадии. Он подтверждает завершение.

Если status-стадия падает, хост может сообщить о тайм-ауте, даже если часть данных уже была обменена.

Путаница с пакетами нулевой длины

Пакет нулевой длины — это не автоматически «нет данных» на уровне приложения. В управляющих передачах он может быть обязательным хендшейком status-стадии.

Частые ошибки:

• Прошивка не отвечает ACK на status-стадию.
• Хост ожидает status-пакет нулевой длины, а получает STALL.
• Устройство шлёт данные, когда status должен быть пустым.
• Вендорная команда завершает data-стадию, но падает на финальном хендшейке.
• Стейт-машина прошивки забывает вооружить endpoint 0.

Эти ошибки часто встречаются в нестандартных вендорных командах и загрузчиках.

Endpoint 0 особенный

Endpoint 0 обслуживает перечисление и управляющие запросы. Если состояние endpoint 0 испорчено, всё устройство может стать нестабильным.

Симптомы:

• Перечисление начинается, но падает на следующем дескрипторе.
• Вендорный запрос срабатывает один раз, затем ставит stall.
• После управляющей передачи устройство нужно вытащить и вставить заново.
• SET_ADDRESS или SET_CONFIGURATION работают нестабильно.
• HID Feature Report через управляющий канал падает.
• DFU-запрос detach возвращается, но устройство не переходит в режим.

Bus Scope должен показать, восстановился ли endpoint 0 после stall или остался сломан.

IN vs OUT управляющие передачи

Направление status-стадии меняется вместе с направлением управляющей передачи.

Для IN-запроса:

• Хост шлёт SETUP.
• Устройство шлёт DATA.
• Хост шлёт status OUT-пакет нулевой длины.

Для OUT-запроса:

• Хост шлёт SETUP.
• Хост шлёт DATA, если есть.
• Устройство шлёт status IN-пакет нулевой длины.

Ошибки прошивки часто возникают, когда одно направление тестируется чаще другого.

Сбои дескрипторов vs вендорных команд

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

Что должно быть в данных:

• bmRequestType.
• bRequest.
• wValue.
• wIndex.
• wLength.
• Реальная длина данных.
• Результат status-стадии.
• STALL, NAK, тайм-аут или reset.

Поля setup-пакета нужно интерпретировать вместе с наблюдаемым поведением стадий.

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

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

1. Захватите полную управляющую передачу.
2. Декодируйте поля SETUP.
3. Определите направление передачи.
4. Проверьте ожидаемый размер данных.
5. Сверьте байты data-стадии.
6. Сверьте направление status-стадии.
7. Ищите пакет нулевой длины.
8. Отметьте stall или тайм-аут.
9. Сравните стандартные и вендорные запросы.
10. Сохраните поведение восстановления endpoint 0.

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

Сбои управляющих USB-передач — это часто сбои status-стадии, а не просто проблемы setup-пакета. Пакеты нулевой длины, состояние endpoint 0, направление и финальный хендшейк имеют значение.

Bus Scope помогает инженеру доказать, упало ли устройство на SETUP, DATA, STATUS, обработке ZLP, восстановлении endpoint 0 или обработке вендорной команды.