AT90USB1287 - отваливается конечная точка Опции

[leg]

Доброго времени суток.
Следующая проблема:
Делаю проект на AT90USB1287, драйвер ПК - libusb-win32.
В устройстве три контрольные точки (кроме control) - две OUT, одна IN, все bulk.

Все вроде работало - но при тестировании вылез следующий трабл: при длительной работе отваливается одна из точек OUT. Отваливается в моменты обмена,в обмене постоянно участвует точка IN и точка OUT(та что в последствии отваливается). При этом остальные точки продолжают работать нормально, само устройство в целом продолжает нормально функционировать. Зависшая точка не вызывает никаких прерываний, вообще никак не реагирует. Сброс-переконфигурирование точки не помогает. Восстанавливается только после выключения-включения интерфейса.

За основу кода брал аппноуты от атмел.
С USB на МК работаю впервые, может кто подскажет куда копать?

[kovigor]

может кто подскажет куда копать?

Насколько я помню, если точка "отваливается", то она должна возвращать STALL при попытке записи в нее. Получив STALL, хост обязан сбросить эту точку запросом "Clear_Feature". Это происходит ? И вообще, что будет, если для "отвалившейся" точки подать этот запрос вручную, воспользовавшись тем же BusHound'ом ?

Сообщение отредактировал kovigor - Jan 9 2011, 07:56

[leg]

Насколько я помню, если точка "отваливается", то она должна возвращать STALL при попытке записи в нее. Получив STALL, хост обязан сбросить эту точку запросом "Clear_Feature". Это происходит ? И вообще, что будет, если для "отвалившейся" точки подать этот запрос вручную, воспользовавшись тем же BusHound'ом ?

STALL не возвращается. Точка вообще никак не реагирует на запись, не один флаг не изменяется. Ручной запрос "Clear_Feature" проходит, МК запрос обрабатывает, но на состоянии точки это не отражается. Сброс конечной точки тоже не помогает, помогает только usb-сброс.

[kovigor]

STALL не возвращается. Точка вообще никак не реагирует на запись, не один флаг не изменяется. Ручной запрос "Clear_Feature" проходит, МК запрос обрабатывает, но на состоянии точки это не отражается. Сброс конечной точки тоже не помогает, помогает только usb-сброс.

Я с вашим МК не работал, но те USB-движки, которые мне встречались в разных МК, всегда записывали информацию о статусе конечных точек в соотв. регистры. Т.е., это я к тому, что отключению точки что-то предшествовало. Что ? Data Toggle error ? Прием слишком короткого или длинного пакета ? Или еще что-то ? Попробуйте этот статус при каждом прерывании от этой точки выводить по UART в машину и анализировать, или выводить пользователю для наблюдения каким-то иным способом. Наконец, попробуйте сменить ОС, например, с XP на Win2000. Но начинать надо, думаю, с МК ...

[leg]

Я с вашим МК не работал, но те USB-движки, которые мне встречались в разных МК, всегда записывали информацию о статусе конечных точек в соотв. регистры. Т.е., это я к тому, что отключению точки что-то предшествовало. Что ? Data Toggle error ? Прием слишком короткого или длинного пакета ? Или еще что-то ? Попробуйте этот статус при каждом прерывании от этой точки выводить по UART в машину и анализировать, или выводить пользователю для наблюдения каким-то иным способом.

Так и делаю, т.к. точка IN всегда работоспособна я постоянно считываю все регистры проблемной точки через нее. Никаких изменений вообще нет, после зависания регистры находятся в нормальном состоянии после приема последнего принятого пакета - дальше никаких прерываний и изменений регистров зависшей точки не происходит. Как будто пакеты просто не передаются - хотя они передаются(смотрю программным сниффером) и возвращают ошибку.

[leg]

В общем проблему победил. Правда всего механизма ликвидации проблемы так и не понял.
Т.к. я мало знаком с программированием драйверов под ПК может кто что подскажет:

Как я уже писал со стороны МК никаких ошибок не возникало, точка находилась в рабочем сконфигурированном состоянии и вела себя так как будто никаких запросов просто не приходило, т.е. просто никак не реагировала.

Для ликвидации зависания необходимо было осуществить сброс точки, вот только сброс точки с МК напрямую(внешним прерыванием, по uart и тп.) или сторонним ПО (BUS Hound) посылкой "clear feature" не приводило не к каким результатам - МК отрабатывал запрос но точка так и не работала. Что бы восстановить точку необходимо осуществить сброс точки с того экземпляра драйвера с которого произошла ошибка - т.е. послать "clear feature" с управляющего ПО в котором ошибка и произошла. При этом МК делал все то же самое что и при ручном сбросе - но точка восстанавливалась. Насколько я понял смысл этого действия заключался в сбросе ошибки в самом драйвере а не в МК, хотя могу ошибаться.

Причина замирания точки так и не выяснена, но думаю на несколько сотен тысяч пакетов по 256 байт в полноскоростном режиме один битый пакет - это нормально, не ясно только почему в МК это не как не отразилось.