Зависание устройства USB CDC

Я пишу простое устройство виртуального последовательного порта, чтобы сообщить о старом последовательном порту. К этому моменту я могу перечислить устройства и отправить / получить символы.

После различного количества массовых передач от хоста к устройству конечная точка, похоже, отказывается и прекращает передачу данных. На стороне ПК я получаю ошибку записи, и, судя по трассировке USBlyzer, музыка останавливается (USBD_STATUS_STALL_PID). Однако мой код никогда намеренно не выдает состояние STALL для этой конечной точки, а флаг состояния для его создания никогда не устанавливается.

Учитывая небольшой промежуток времени, прошедший (‹300 мкс) между выдачей запроса и STALL, это может показаться неким недопустимым ответом, а не тайм-аутом. На стороне устройства конечная точка вывода готова к работе с данными в буфере и надлежащей синхронизацией DATA0 / 1, но больше ничего не происходит.

Обратите внимание, что устройство работает нормально даже в течение длительного времени, пока я не начну отправлять «большие» объемы данных. Насколько я могу судить, перечисление / конфигурация устройств также успешно завершается. Да, и после этого конечная точка массового ввода продолжает нормально работать.

Для записи я использую стандартный драйвер Windows usbser.sys и микропроцессор XMega128A4U. Я также наблюдаю такое же поведение на нескольких машинах с Windows Vista и 7.

Есть идеи, что я делаю неправильно или какие дополнительные тесты я могу провести, чтобы сузить круг вопросов?

журнал USBlyzer, стек USB CDC, тестовый проект


person doynax    schedule 12.11.2012    source источник


Ответы (2)


Для протокола это в конечном итоге оказалось проблемой осциллятора. (Очевидно, эталонный сигнал FLL всегда равен 1024 Гц, даже если выбраны кадры USB с частотой 1000 Гц. Небольшая ошибка синхронизации означала, что пакет иногда отклонялся, если он содержал один слишком много 1-битов подряд.)

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

person doynax    schedule 24.11.2012

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

Обратите внимание, что устройство работает нормально даже в течение длительного времени, пока я не начну отправлять «большие» объемы данных.

Похоже, это намек на переполнение буфера вывода.

person Habi    schedule 12.11.2012
comment
О, я подумал, что существует механизм управления потоком, основанный на обычных NACK для устройств CDC. Есть идеи, как тогда ограничивается скорость? Если верить журналу USBlyzer, то последний раз устройство считывало данные за ~ 30 мс до остановки. - person doynax; 13.11.2012