В процессе отладки USB Device на AT91RM9200 я заметила странную закономерность:

при включении питания моего устройства после выключения питания на ДОЛГОЕ ВРЕМЯ (минуты 3 хотя бы или даже больше, а лучше вобще включать устройство с утра или после обеда ) после загрузки программы и подключении девайса к хосту начинается процесс enumeration. Девайсу назначается адрес, и дескриптор устройства отсылается хосту. Этот процесс я еще отлаживаю, пока он не работает правильно: хост пока не понимает этот дескриптор и повторяет свои попытки 3 раза. Но не в этом проблема.

Далее я либо выключаю-включаю Pull-up резистор, либо откючаю-включаю устройство с помощью кабеля, процесс enumeration уже представляет собой другую последовательность транзакций (адрес уже не устанавливается, иногда не возникают прерывания по EPOINT0. И с течением времени обмен совсем ломается: при обнаружении устройства в Windows моему устройству приходит только набор прерываний ENDBUSRESET и RXRSM и ни одного EPOINT0 (то есть никаких запросов и никаких установок).

Я бы думала, что это все связано с глюками моей программы, НО
если затем я сбрасываю питание устройства (в выключенном состоянии устройство находится НЕДОЛГО), то нормальный обмен (как после долгого выключения устройства) не восстанавливается.

А если я выключу устройство снова надолго, то начало процесса enumeration происходит нормально (как в первом случае).

Но самая странная ситуация такая:
если оставить питание устройства выключенным надолго (чтобы обмен был полным, как в первом случае),
затем включить устройство, но программу не загружать в контроллер какое-то время,
а потом загрузить и сразу подключить девайс к хосту, то нормального первоначального обмена нет.

То есть процесс enumeration происходит нормально только после длительного ресета и при подключении устройста к хосту сразу же после подачи питания на устройство.
Через какое-то время обмен ломается независимо от программы.

Спасибо всем, кто дочитал до конца!
Подскажите, пожалуйста, в чем может быть дело? Схемотехник говорит, что "схемотехнически все правильно и ничего там не может быть".
И я тоже не знаю, что делать

Прочитал но ничего не понял. Чтобы отлаживать с 0 необходимо иметь сниффер( сканирует потоки аппаратно по шине). И как вы определяете этапы что прошло и что ответило? какой драйвер стоит на компе? ведь буквально через 4-5 стандартных запросов от Винды подзагружаются ответственные за данный дескриптор драйвер и именно они продолжают стандартные запросы( а в последствии и не стандартные).

Я вывожу по DBGU основные моменты (названия функций, типы принятых пакетов), поэтому знаю, какая последовательность запросов/ответов выполняется

До драйвера еще не дошло, к сожалению, потому что хост не понимает мой дескриптор устройства. Сам дескриптор передается, но, видимо, не хватает какого-то подтверждения (пакета 0-й длины от хоста, наверное). Поэтому хост 3 раза повторяет попытки получить дескриптор и прекращает это делать.

Первый раз слышу про сниффер. Не расскажите поподробнее, что это и где его взять?
Спасибо.

Это, например, Bus Hound.
Есть и другие подслушивающие программы, но я ими не пользовался.

Мой опыт - на этапе подключения USB device (обмен дескрипторами и прочее) вывод отладочных сóобщений через DBGU порт занимает кучу времени, нарушая тем самым временные ограничения в PC (я так думаю, по крайней мере). Посему, это не вариант для отладки.

Программные снифферы на этом этапе тоже не помогут. Они реально показывают обмен пакетами только, когда USB device уже "подцепился" к host'у.

А если попробовать WinDriver - я высматривал пакеты на этапе подключения; просто в ручном режиме запрашивать дескрипторы.

Я, в принципе, тоже думала, что вывод сообщений по DBGU может внести значительную для USB задержку. Но вроде ничего, работает. Я нашла ошибку в примере от Atmel, дописала код немножко, и теперь мое устройство прекрасно обнаруживается в Windows.
Но основная проблема, о которой я писала в первом сообщении этой темы, так и осталась нерешенной.
Кратко ее суть: если подключать мое устройство (на AT91RM9200) по USB к хосту сразу (в течении неск-х секунд, не более минуты) после включения питания устройства, то оно нормально обнаруживается в Windows. А если подключать устройство к хосту после некотрой паузы после включения питания, то оно уже не определяется корректно. Не проходит стадия enumeration. И чем больше время после включения питания устройства до подключения его к хосту, тем хуже.
Как будто при включении питания на плате контроллера ЧТО-ТО заряжается, что в дальнейшем портит обмен UDP с хостом. А чтобы устройство снова корректно обнаружилось в Windows, надо достаточно на длительное время выключить его блок питания. Возможно чтобы это НЕЧТО успело разрядиться.

Наш схемотехник пока не может найти в чем причина.
Никто не сталкивался с такой проблемой?

Буду благодарна за любые идеи! Спасибо.

Ну вот, моя проблема решилась сама собой. Мы включили второе такое же устройство (на AT91RM9200), и оно отлично заработало! Нет никаких глюков, связанных с длительностью включения и выключения устройства и работой USB.
Пока схемотехник не знает, в чем разница между двумя "абсолютно одинаковыми" платами, но когда он выяснит это, могу написать, если кому-то интересно.

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

Не поленюсь в десятый раз повторить на этом форуме: "Программирование, это наука о контактах (и о взаимоотношениях программистов с производством)".

Все, как вы и сказали. Нашелся непропай где-то в цепи питания микроконтроллера.