Подскажите, пожалуйста, как решить следующую проблему с прерываниями UDP ENDBUSRES и RXRSM.

Пока устройство не подключено к компьютеру, постоянно идут прерывания ENDBUSRES и RXRSM (поочередно).
После подключения устройства к хосту, эти прерывания перестают генерироваться до включения Pull-up.
Прерывание ENDBUSRES мешает мне передать дескриптор устройства на хост:
подключаю устройство (на AT91RM9200) к компьютеру, включаю PullUp,
возникает прер-ие ENDBUSRES,
затем прер-ие EPOINT0 - получаю пакет SETUP (запрос дескриптора устройства),
передаю первые 8 из 18 байт,
снова прерывание по EPOINT0 - по флагу TX_COMP,
передаю следующие 8 байт дескриптора,
а вот здесь снова возникает прерывание по ENDBUSRES
и я уже никогда не передаю последние 2 байта дескриптора устройства.

Из-за чего это случается? Когда должно происходить прер-ие ENDBUSRES? Только после подключения устройства к хосту и только 1 раз?
И как отключить RXRSM?

AT91F_UDP_DisableIt(AT91C_BASE_UPD, AT91C_UPD_RXRSM) в обработчике прерывания по ENDBUSRES не помогает.

Спасибо.

Я бы все остальные прерывания разрешал только по приходу ENDBUSRESET. И вообще все прерывания надо чистить записью в UDP_ ICR. Так же ENDBUSRESET можно не давать генерировать прерывания UDP_ IDR. Ну и т.д.

Я не разрешаю никаких прерываний до возникновения прерывания ENDBUSRESET. По этому прерыванию разрешаю только прерывания по EPOINT0, а RXRSM запрещаю. Но ENDBUSRESET и RXRSM все равно генерятся после этого.

В каких случаях вообще генерируются ENDBUSRESET и RXRSM по теории?
Что означает, что они все время генерируются до подключения устройства, а также после подключения устройства и включения Pull-Up?

Смотря, что вы подразумеваете под словом "генерируются". Флаги взводятся. Но они не должны вызывать прерывания. Прерывания вызывает, как я понимаю, приход пакета. В обработчике прерывания вы должны первым делом применить маску рарешенных прерываний на регистр статуса и обрабатывать только то, что осталось. (status = ISR & IMR). В конце прерывания не забывайте писать в AIC_EOICR. В то же время, если вы производите запись в этот регистр дважды (в собственно обработчике и общей "обертке", например) то тоже возможны проблеммы.

Я делаю так:

А потом проверяю побитно, какие прерывания возникли.
Это пример для SAM7S.
UDP_ISR - регистр статуса прерываний - то есть какие прерывания произошли.
UDP_IMR - регистр маски прерываний - то есть какие прерывания разрешены (мною в программе).

Это типичный "глюк" Windows который вводит в ступор программистов.
Windows посылает запрос с разрешенной длиной ответа 256 байт, а реально после приема первого пакета в 8 байт(или 16 зависит от длины эндпоита) Сразу генерит сброс шины.
По приему сигнала ENDBUSRES устройство должно прекратить передачу.
Затем Windows определив длину ответа, еще раз пошлет запрос с разрешенной длиной ответа равной длине дескриптора.
Но в любом случае ENDBUSRES нужно отрабатывать одинаково.

C RXRSM у меня тоже были проблемы(SAM7S128)
Некорректно был составлен стартап от IAR

После добавления 8 сбросов контроллеру прерывания, до разрешения прерываний

Все заработало.

О "глюке" Windows я читал по моему здесь, в конце документа:
http://www.beyondlogic.org/usbnutshell/usb-in-a-nutshell.pdf

Спасибо, эта информация мне помогла. Но только не пойму, что конкретно в стартапе у вас было неверно? У меня, например, в функции LowLevelInit есть 8 сбросов контроллеру прерывания до разрешения прерываний, но прерывания по флагу RXRSM все равно генерятся.
В PDF-ке написано, что после ресета эти прер-ия действительно разрешены, но я их запрещаю в обработчике прерывания по ENDBUSRES, а они все равно идут.
Не подскажите, в чем может быть проблема?

Может от того что SAM7S уже скоро как два года выпускается а документация все preliminary? ;-)

По моему у нас работало корректно.
Попробуйте RXRSM обрабатывать - то есть просто сбрасывайте.
По включению питания может случайно взвестись.

С документацией все в порядке, у меня к тому же AT91RM9200, а не SAM7S.
Но все-равно спасибо
А Что по этому поводу изменилось в последней документации для SAM7S по сравнению с preliminary?

Она по прежнему preliminary:
http://www.atmel.com/dyn/products/datashee...ily_id=605#1586

Я тоже не смог замаскировать прерывание ENDBUSRES на AT91SAM7S256. Похоже, что это нельзя сделать

По моему опыту запретить прерывание ENDBUSRES просто не возможно. Нет даже в Datashit
в регистре _IDR такого бита.В момент сброса линии стирается _IMR ( становится =0x13 что равно
прерываниям ENDBUSRES + RXRSM +RXSUSP). а также разрешаются все прерывания.
В обработчике надо просто игнорировать эти прерывания, но в AIC посадить срабатывание по фронтам.
Сложнее другое, в работе могут разрешенные ранее прерывания по точке просто само отменяться(скорее всего глюк атмела). Для исправления можно включить таймер и по его прерыванию иногда восстанавливать _IER . Особенно обратите внимание на разницу в стандартах 1.1 и 2.0 по нулевым ответам на запросы от хоста. Так в 2.0 при передачи пакетов с длиной кратной объему точки нужно послать в конце и пакет нулевой длины ( исключение - если хост послал в 0 точку запрос на 8,16,24...
байт и столько же содержится в дескрипторе нг передачу).

Странно все это. У меня все прекрасно работает без всяких извратов. Правда прибор еще в разработке, но может что и выловится. Так же не видел никаких извратов в Атмеловских примерах...

по поводу "глюка" Windows... это стандартное поведение USB протокола описанное в спецификации. Так как дескриптор девайса может быть разного размера, то для его получения винда отсылает запрос на получение дескриптора, и получив первые 8 байт резетит девайс. Так как в этих восьми байтах содержится информация о полном размере дескриптора, то винда второй раз посылает запрос на получение дескриптора уже правильной длины.
Ещё тут говорилось о том, чтобы игнорировать или запретить ENDBUSRES этого тоже делать не надо... надо его правильно обрабатывать, как описано в протоколе USB... пример можно найти на сайте атмела...

З.Ы. звиняйте, что поднимаю старую тему... давно не был...