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

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

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

- вошли в первое прерывание от TX_COMP
- отправили второй пакет
- достаточно долго чем-то занимались
- пришло второе прерывание от TX_COMP (но мы еще обрабатываем первое)
- наконец-то решили выйти из обработчика прерывания
- записали в AIC_EOICR (тем самым игнорируя второе прерывание от TX_COMP [оно небось по фронту])
- вышли из первого прерывания

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

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

Сообщение отредактировал YKonstantin - May 29 2007, 08:09

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

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

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

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

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

Что и требовалось доказать! Теперь я на 100% уверен, что в модуле UDP у SAM7S64 - косяк.
У них такая же херня с модулем TWI.
Спасибо за проявленный интерес!
В итоге я все-таки добился устраивающего меня результата: пустил весь обмен данными через EP1 и EP2, там размер конечной точки равен размеру кадра (64 байта), так что обошелся без "подкачки".

Подскажите по очень похожему вопросу - в теме решение своей проблемы не нашел.
Тоже 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 идентичны до сбоя).

Это классические грабли.
Windows псоле получения первых 8 байт дескриптора устройства - поизводит BUS_RESET.
Потом опять шлет запрос дескриптора и получает его целиком.

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

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

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

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

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

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


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

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