|
|
  |
Прерывания ENDBUSRES и RXRSM |
|
|
|
May 10 2007, 11:45
|
Участник

Группа: Новичок
Сообщений: 69
Регистрация: 12-10-05
Из: Калуга
Пользователь №: 9 539

|
Подскажите, пожалуйста, как решить следующую проблему с прерываниями 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 не помогает.
Спасибо.
|
|
|
|
|
May 11 2007, 10:43
|
Участник

Группа: Новичок
Сообщений: 69
Регистрация: 12-10-05
Из: Калуга
Пользователь №: 9 539

|
Цитата(Dron_Gus @ May 10 2007, 20:50)  Я бы все остальные прерывания разрешал только по приходу ENDBUSRESET. И вообще все прерывания надо чистить записью в UDP_ ICR. Так же ENDBUSRESET можно не давать генерировать прерывания UDP_ IDR. Ну и т.д. Я не разрешаю никаких прерываний до возникновения прерывания ENDBUSRESET. По этому прерыванию разрешаю только прерывания по EPOINT0, а RXRSM запрещаю. Но ENDBUSRESET и RXRSM все равно генерятся после этого. В каких случаях вообще генерируются ENDBUSRESET и RXRSM по теории? Что означает, что они все время генерируются до подключения устройства, а также после подключения устройства и включения Pull-Up?
Сообщение отредактировал junkl - May 11 2007, 10:53
|
|
|
|
|
May 11 2007, 11:24
|
Знающий
   
Группа: Свой
Сообщений: 601
Регистрация: 22-09-05
Из: Kharkov
Пользователь №: 8 847

|
Я делаю так: Код unsigned int isr = UDP->UDP_ISR & UDP->UDP_IMR; А потом проверяю побитно, какие прерывания возникли. Это пример для SAM7S. UDP_ISR - регистр статуса прерываний - то есть какие прерывания произошли. UDP_IMR - регистр маски прерываний - то есть какие прерывания разрешены (мною в программе).
--------------------
- А мораль отсюда такова: всякому овощу свое время. Или, хочешь, я это сформулирую попроще: никогда не думай, что ты иная, чем могла бы быть иначе, чем будучи иной в тех случаях, когда иначе нельзя не быть. © Lewis Carroll. Alice's adventures in wonderland.
|
|
|
|
|
May 11 2007, 11:48
|
Знающий
   
Группа: Свой
Сообщений: 716
Регистрация: 27-05-05
Из: Kyiv
Пользователь №: 5 454

|
Цитата Прерывание ENDBUSRES мешает мне передать дескриптор устройства на хост: подключаю устройство (на AT91RM9200) к компьютеру, включаю PullUp, возникает прер-ие ENDBUSRES, затем прер-ие EPOINT0 - получаю пакет SETUP (запрос дескриптора устройства), передаю первые 8 из 18 байт, снова прерывание по EPOINT0 - по флагу TX_COMP, передаю следующие 8 байт дескриптора, а вот здесь снова возникает прерывание по ENDBUSRES и я уже никогда не передаю последние 2 байта дескриптора устройства. Это типичный "глюк" Windows который вводит в ступор программистов. Windows посылает запрос с разрешенной длиной ответа 256 байт, а реально после приема первого пакета в 8 байт(или 16 зависит от длины эндпоита) Сразу генерит сброс шины. По приему сигнала ENDBUSRES устройство должно прекратить передачу. Затем Windows определив длину ответа, еще раз пошлет запрос с разрешенной длиной ответа равной длине дескриптора. Но в любом случае ENDBUSRES нужно отрабатывать одинаково. C RXRSM у меня тоже были проблемы(SAM7S128) Некорректно был составлен стартап от IAR После добавления 8 сбросов контроллеру прерывания, до разрешения прерываний Код for (j=0; j<8; j++) AT91C_BASE_AIC->AIC_EOICR = 0; Все заработало. О "глюке" Windows я читал по моему здесь, в конце документа: http://www.beyondlogic.org/usbnutshell/usb-in-a-nutshell.pdf
|
|
|
|
|
May 17 2007, 11:28
|
Участник

Группа: Новичок
Сообщений: 69
Регистрация: 12-10-05
Из: Калуга
Пользователь №: 9 539

|
Цитата(misyachniy @ May 11 2007, 15:48)  Это типичный "глюк" Windows который вводит в ступор программистов. Windows посылает запрос с разрешенной длиной ответа 256 байт, а реально после приема первого пакета в 8 байт(или 16 зависит от длины эндпоита) Сразу генерит сброс шины. По приему сигнала ENDBUSRES устройство должно прекратить передачу. Затем Windows определив длину ответа, еще раз пошлет запрос с разрешенной длиной ответа равной длине дескриптора. Но в любом случае ENDBUSRES нужно отрабатывать одинаково. C RXRSM у меня тоже были проблемы(SAM7S128) Некорректно был составлен стартап от IAR После добавления 8 сбросов контроллеру прерывания, до разрешения прерываний Код for (j=0; j<8; j++) AT91C_BASE_AIC->AIC_EOICR = 0; Все заработало. О "глюке" Windows я читал по моему здесь, в конце документа: http://www.beyondlogic.org/usbnutshell/usb-in-a-nutshell.pdfСпасибо, эта информация мне помогла. Но только не пойму, что конкретно в стартапе у вас было неверно? У меня, например, в функции LowLevelInit есть 8 сбросов контроллеру прерывания до разрешения прерываний, но прерывания по флагу RXRSM все равно генерятся. В PDF-ке написано, что после ресета эти прер-ия действительно разрешены, но я их запрещаю в обработчике прерывания по ENDBUSRES, а они все равно идут. Не подскажите, в чем может быть проблема?
|
|
|
|
|
May 17 2007, 12:05
|
Знающий
   
Группа: Свой
Сообщений: 716
Регистрация: 27-05-05
Из: Kyiv
Пользователь №: 5 454

|
Цитата(junkl @ May 17 2007, 14:28)  Спасибо, эта информация мне помогла. Но только не пойму, что конкретно в стартапе у вас было неверно? У меня, например, в функции LowLevelInit есть 8 сбросов контроллеру прерывания до разрешения прерываний, но прерывания по флагу RXRSM все равно генерятся. В PDF-ке написано, что после ресета эти прер-ия действительно разрешены, но я их запрещаю в обработчике прерывания по ENDBUSRES, а они все равно идут. Не подскажите, в чем может быть проблема? Может от того что SAM7S уже скоро как два года выпускается а документация все preliminary? ;-) По моему у нас работало корректно. Попробуйте RXRSM обрабатывать - то есть просто сбрасывайте. По включению питания может случайно взвестись.
|
|
|
|
|
May 17 2007, 13:19
|
Участник

Группа: Новичок
Сообщений: 69
Регистрация: 12-10-05
Из: Калуга
Пользователь №: 9 539

|
Цитата(misyachniy @ May 17 2007, 16:05)  Может от того что SAM7S уже скоро как два года выпускается а документация все preliminary? ;-)
По моему у нас работало корректно. Попробуйте RXRSM обрабатывать - то есть просто сбрасывайте. По включению питания может случайно взвестись. С документацией все в порядке, у меня к тому же AT91RM9200, а не SAM7S. Но все-равно спасибо  А Что по этому поводу изменилось в последней документации для SAM7S по сравнению с preliminary?
|
|
|
|
|
May 17 2007, 14:24
|
Знающий
   
Группа: Свой
Сообщений: 716
Регистрация: 27-05-05
Из: Kyiv
Пользователь №: 5 454

|
Цитата(junkl @ May 17 2007, 16:19)  С документацией все в порядке, у меня к тому же AT91RM9200, а не SAM7S. Но все-равно спасибо  А Что по этому поводу изменилось в последней документации для SAM7S по сравнению с preliminary? Она по прежнему preliminary: http://www.atmel.com/dyn/products/datashee...ily_id=605#1586
|
|
|
|
|
May 18 2007, 18:36
|
Группа: Новичок
Сообщений: 4
Регистрация: 18-05-07
Пользователь №: 27 820

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

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