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 всегда работоспособна я постоянно считываю все регистры проблемной точки через нее. Никаких изменений вообще нет, после зависания регистры находятся в нормальном состоянии после приема последнего принятого пакета - дальше никаких прерываний и изменений регистров зависшей точки не происходит. Как будто пакеты просто не передаются - хотя они передаются(смотрю программным сниффером) и возвращают ошибку.

[kovigor]

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

Тут бы аппаратным сниффером обмен глянуть. Это было бы гораздо информативнее. Взять у кого - то на пару дней, или самому сделать.
А теперь о личном опыте. Два раза попадал в ситуации, сходные с вашей, когда конечные точки выходили из повиновения, и ничто не могло пролить свет на эти загадки. Один раз - с ARM7, второй - с ARM9. После многих дней экспериментов источник проблемы был найден. В первом случае ядро МК работало на слишком низкой частоте и при интенсивном обмене в определенный момент просто переставало справляться с обработкой USB трафика. Во втором случае обработчик прерывания от USB был построен не совсем удачно (кстати, проект делался на основе готового Атмеловского примера), благодаря чему на обработку прерываний тратилось слишком много времени. Мой вам совет - если изучение исходников и документации не помогает, попробуйте поднять тактовую частоту МК. Не поможет - берите аппаратный сниффер и закапывайтесь более глубоко ...

... на несколько сотен тысяч пакетов по 256 байт ...

Ой, а что это за размер такой у вас ? В спецификации сказано, что для Bulk на FS размер пакета не может быть больше 64 байт, а на HS - 512 байт. Как я понял из той же спецификации, использовать 256 байт на HS в принципе возможно, но это не рекомендуется, т.к. хост не обязан поддерживать такой размер. У вас FS. Вас это не настораживает ?