[yablunivsky 0]

А вот еще вариант : может слишком долго в прерывании сидите после отправки данных?

Я к тому, что перед выходом из обработчика надо сбросить флаг в AIC, а если до этого пришло следующее прерывание то вы его получается принудительно сбросите ...

[sgrig 0]

А вот еще вариант : может слишком долго в прерывании сидите после отправки данных?

Я к тому, что перед выходом из обработчика надо сбросить флаг в AIC, а если до этого пришло следующее прерывание то вы его получается принудительно сбросите ...

Как я писАл ранее, кроме TX_COMP и STALLSENT, от других флагов прерывания идут.

[yablunivsky 0]

Как я писАл ранее, кроме TX_COMP и STALLSENT, от других флагов прерывания идут.

 

Я говорил о такой ситуации :

 

- вошли в первое прерывание от TX_COMP

- отправили второй пакет

- достаточно долго чем-то занимались

- пришло второе прерывание от TX_COMP (но мы еще обрабатываем первое)

- наконец-то решили выйти из обработчика прерывания

- записали в AIC_EOICR (тем самым игнорируя второе прерывание от TX_COMP [оно небось по фронту])

- вышли из первого прерывания

 

Итог : второго прерывания как бы и небыло ...

 

Еще "в догонку" : в свое время лажанулся - разрешал прерывание от контрольной точки ДО ее конфигурирования. Как результат : прерываний от приемника не получал ...

Изменено 29 мая, 2007 пользователем YKonstantin

[sgrig 0]

Я говорил о такой ситуации :

 

- вошли в первое прерывание от TX_COMP

- отправили второй пакет

- достаточно долго чем-то занимались

- пришло второе прерывание от TX_COMP (но мы еще обрабатываем первое)

- наконец-то решили выйти из обработчика прерывания

- записали в AIC_EOICR (тем самым игнорируя второе прерывание от TX_COMP [оно небось по фронту])

- вышли из первого прерывания

 

Итог : второго прерывания как бы и небыло ...

 

Еще "в догонку" : в свое время лажанулся - разрешал прерывание от контрольной точки ДО ее конфигурирования. Как результат : прерываний от приемника не получал ...

 

При отправке статуса (пакета нулевой длины) из прерывания вываливаюсь сразу же после установки флага TXPKTRDY - прерывания от TXCOMP нет. Сам же флаг устанавливается - проверял поллингом. С механизмом прерываний тоже все вроде бы правильно - остальные то идут.

Прерывание, естественно, открывается в последнюю очередь.

А у Вас "подкачка" в прерывании получилась?

[yablunivsky 0]

При отправке статуса (пакета нулевой длины) из прерывания вываливаюсь сразу же после установки флага TXPKTRDY - прерывания от TXCOMP нет. Сам же флаг устанавливается - проверял поллингом. С механизмом прерываний тоже все вроде бы правильно - остальные то идут.

Прерывание, естественно, открывается в последнюю очередь.

А у Вас "подкачка" в прерывании получилась?

 

Я использую не-HID протокол.

Поэтому в контрольной точке жульничаю - отправляю ответы с ожиданием (для пакетов 0-й длины "AT91C_UDP_TXCOMP", а для "штопора" - "AT91C_UDP_ISOERROR").

 

Для получения данных большого (>8-ми байт) обьема использую прием в "Bulk" точку №1.

При этом использую "пинг-понг". Так вот в этом самом случае возникала ситуация, когда я приняв все данные из одного буфера выходил из прерывания не проверив "а не успел ли за это время заполниться второй буфер", и тем самым терял прерывание (мы ведь помним о записи в AIC_EOICR) от приема во второй буфер.

[sgrig 0]

Я использую не-HID протокол.

Поэтому в контрольной точке жульничаю - отправляю ответы с ожиданием (для пакетов 0-й длины "AT91C_UDP_TXCOMP", а для "штопора" - "AT91C_UDP_ISOERROR").

То есть TXCOMP и STALLSENT также поллингуете (ждете в цикле)?

[yablunivsky 0]

То есть TXCOMP и STALLSENT также поллингуете (ждете в цикле)?

 

Да.

Собственно ф-ции посылки без изменения взяты из CDC-шного примера.

[sgrig 0]

Да.

Собственно ф-ции посылки без изменения взяты из CDC-шного примера.

Что и требовалось доказать! Теперь я на 100% уверен, что в модуле UDP у SAM7S64 - косяк.

У них такая же херня с модулем TWI.

Спасибо за проявленный интерес!

В итоге я все-таки добился устраивающего меня результата: пустил весь обмен данными через EP1 и EP2, там размер конечной точки равен размеру кадра (64 байта), так что обошелся без "подкачки".

[Serg_Sm 0]

Подскажите по очень похожему вопросу - в теме решение своей проблемы не нашел.

Тоже SAM7S64. Процесс энумерации без прерываний.

Проблема в сбое энумерации - возникает не всегда и не на каждой системе. Но нашел один комп, на котором такое постоянно происходит (на других все тесты USB2CV проходят без ошибок).

 

1) по ENDBUSRESET сброс EP и т.п.;

2) Получаю запрос на дескриптор устройства;

3) Первые 8 байт дескриптора загружаю в FIFO и поднимаю TXPKTRDY, сбрасываю TXCOMP;

4) Жду TXCOMP, посылаю следующие 8 байт (поднимая TXPKTRDY), сбрасываю TXCOMP.

И вот здесь наблюдается затык, потому что хост прервал получение дескриптора и уже шлет "Set Address":

В UDP_CSR0 выставляется RXSETUP, но данных нет (FIFO занял отправленный ранее запрос) - соответственно обмен остановлен.

Признака по которому видно, что хост прервал транзакцию я не нашел - транзакции с обрывом и полной передачей данных идут одинаково (состояния UDP_ ISR и UDP_CSR0 идентичны до сбоя).

[misyachniy 0]

1) по ENDBUSRESET сброс EP и т.п.;

2) Получаю запрос на дескриптор устройства;

3) Первые 8 байт дескриптора загружаю в FIFO и поднимаю TXPKTRDY, сбрасываю TXCOMP;

4) Жду TXCOMP, посылаю следующие 8 байт (поднимая TXPKTRDY), сбрасываю TXCOMP.

И вот здесь наблюдается затык...

 

Это классические грабли.

Windows псоле получения первых 8 байт дескриптора устройства - поизводит BUS_RESET.

Потом опять шлет запрос дескриптора и получает его целиком.

 

Нужно по ENDBUSRESET обязательно отменять передачу дескриптора, да и любые передачи.

 

[Serg_Sm 0]

Это классические грабли.

Windows псоле получения первых 8 байт дескриптора устройства - поизводит BUS_RESET.

Потом опять шлет запрос дескриптора и получает его целиком.

 

Нужно по ENDBUSRESET обязательно отменять передачу дескриптора, да и любые передачи.

8-ка и 10-ка не производит BUS_RESET (после получения 8 байт дескриптора - скорость так подняли). В общем решил так - после BUS_RESET передаю только 8 байт дескриптора. Нашел про это в стандарте (п.5.5.3 USB2.0) - коряво написано:

In order to determine the maximum packet size for the Default Control Pipe, the USB System Software reads the device descriptor. The host will read the first eight bytes of the device descriptor. The device always responds with at least these initial bytes in a single packet. After the host reads the initial part of the device descriptor, it is guaranteed to have read this default pipe’s wMaxPacketSize field (byte 7 of the device descriptor).

Но вроде так можно.

[aaarrr 63]

Нет, так нельзя. В приведенной цитате сказано, что устройство обязано отдать первые 8 байт одним пакетом, но прерывать после этого передачу по собственному усмотрению нельзя.

[Serg_Sm 0]

Нет, так нельзя. В приведенной цитате сказано, что устройство обязано отдать первые 8 байт одним пакетом, но прерывать после этого передачу по собственному усмотрению нельзя.

Указано "at least". Т.е. отдать по крайней мере 8 байт одним пакетом, значит больше - не обязательно. И к тому же явно указано, что хост читает 8 байт, а не больше. И по другому я вообще без понятия как сделать, поскольку не нашел разницы в обмене полной транзакции и с обрывом. Т.е. ответные данные в FIFO загоняются и следующий пакет SETUP убивает весь обмен.

Тесты USB2CV кстати проходятся без ошибок.

[aaarrr 63]

Указано "at least". Т.е. отдать по крайней мере 8 байт одним пакетом, значит больше - не обязательно.

Это значит, что нельзя, например, отдать эти восемь байт двумя пакетами по 4, а не то что можно не отдавать больше.

 

И к тому же явно указано, что хост читает 8 байт, а не больше. И по другому я вообще без понятия как сделать, поскольку не нашел разницы в обмене полной транзакции и с обрывом.

А в запросе что стоит в wLength?

[Serg_Sm 0]

Это значит, что нельзя, например, отдать эти восемь байт двумя пакетами по 4, а не то что можно не отдавать больше.

 

 

А в запросе что стоит в wLength?

Всё-таки на самой кривой системе запрашивает именно 18 (Windows 8.1 Intel Core i5, чипсет 82801). На других бывает и 8. Так что не определить.