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

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

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

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

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

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

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

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

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

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

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

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




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

Да FS. Меня это самого смущало когда начинал проект. Но в документации на МК сказано что максимальный размер 256 байт. Это первое что я проверил когда выяснил про зависание точки - в плане эксперимента сделал пакеты по 16 байт при той же частоте отправки пакетов(такой трафик меня не устраивает - проверял только ради эксперимента) - все то же самое, примерно через три-четыре часа непрерывной работы точка зависала.

Изначально вообще был запрос 384 байта - максимальный размер ставил 192 в режиме пинг-понг (МК поддерживает). Запрос бился на два пакета самим драйвером, которые посылались друг за другом - МК справлялся точно так же, через несколько часов - та же ошибка.

Сейчас после того как в первом приближении поборол проблему - вернул пинг-понг назад. Все работает. Причем чтобы не ждать несколько часов я вызываю ошибку по другому - после запуска ПО запускаю bulk-tester из пакета libusb и гоню нещадный поток запросов на точку IN - через пару минут таже точка OUT уходит в туже ошибку ошибку(без признаков в МК) - но тут же следует "clear" и следующий пакет все ОК, еще через пару минут то же самое. Если так не издеваться над устройством и работать из основного ПО - ошибка в среднем через 3-4 часа, и тут же востонавливается - пока меня устраивает, хотя из интерреса узнать причину все же хочется.

Что касается частоты ядра - работает на максимале. Что касается трафика - он всегда стабилен - запросы каждые 50мс. На обработку пакета МК всегда тратит одинаковое время. Сам USB работает не по прерываниям а крутится в основном цикле, я просто не могу работать по прерываниям на USB - по прерываниям таймера работает основной функционал - это система управления координатным столом в реальном времени - ни какое прерывание не должно отложить сработку таймера, но обработчик иаймера написан на ассемблере, занимает крайне мало тактов и всегда одинаков по времени выполнения до такта.
К тому же я отключал основной функционал - оставил только основной цикл где идет обработка USB - результат тот же - три часа и ошибка.

Еще что касается максимального размера пакета - само ПО для ПК писалось на основе ПО для другого аналогичного железа(серийно выпускаемого) - не знаю что в нем внутри(не разбирал, оно не у меня) - но его дескрипторы выдают: FS спецификация 2.0, размер пакета 512 байт. Не очень в курсе вопроса, пока курю спецификации, но возможно при использовании FS на спецификации 2.0 а не 1.0-1.1 такая длина пакета все же допустима?

Эх, не стал бы я связываться с USB в таком деле. Ненадежно это. А какой объем данных передается (в секунду) ? Просто интересно ...
P.S. Может, у вас там изохронная точка, а не BULK ? Спецификация у меня 2.0, раздел 5.8.3. Там четко сказано, что макс. размер пакета - 64 байта. На всякий случай открыл описание на свой ARM9 (FS). И там написано то же самое. Подозреваю, что это не случайно. Так что ...

Та на самом деле ничего там страшного нет - реалтайм не для ПК, ПК подготавливает заранее управляющий массив данных и переодически подкидывает MK, весь реалтайм - это всего лиш МК с определенной временной дискретностью валит этот массив на ШД. Естественно внутри МК есть скользящий буфер - так что если У ПК скорость отправки колеблется это никак не влияет и несколько не отправленных пакетов тоже не собьют работу - отработает буфер, если интерфейс совсем ляжет - сработает стоп, стол по возможности плавно остановится на последней координате в буфере - плохо но не смертельно, после перезапуска пойдет дальше.
Система рассчитана на недорогой ЧПУ на базе ШД а не серводвигателей обратная связь в реалтайм сдесь ненужна.



Сейчас тестирую на 25мс/256 байт на OUT и 32 на IN, т.е. около 11K в секунду - полет нормальный.




Та нет именно bulk. Пакеты не бьются, даходят все 256 за один пакет. Сам читал спецификацию, про максимальную длину видел. В любом случае ошибка не из за длины пакета была, на 16байт тоже самое. Но насчет перейти на 64 для соответствия спецификации сейчас думаю. Как я уже писал - основа кода ПК на уже готовом ПО, там вообще 512 через bulk и вроде как у всех работает (жалоб от пользователей в сети не встречал ).

ПО тестировалось на трех машинах с XP и одной 2000, все запускалось без проблем, ошибка что была - одинаково возникала на двух ХР , на 2000 такие длительные тесты не проводились, сейчас после фикса будем тестировать заново на всем.