Непонятки с UDP у SAM7S64 Опции

[sgrig]

Зашел в тупик, бьюсь не первый день. Может, что подскажете?

Делаю HID-устройство на SAM7S64.
Обслуживаю прерывание от EP0 стандартно: получаю запрос, разгребаю его и отправляю в ответ дескриптор или репорт. Для справки: размер EP0 равен 8 байтам, а дескрипторы и репорты могут быть больше.

Суть проблемы:
Если перед загрузкой в FIFO очередной порции данных флаг TXCOMP опрашиваю поллингом в цикле (так сделано в примере HID mouse от Atmel) - все работает как надо, вопросов нет. Но крутиться в прерывании как-то некрасиво.
Если же я начинаю делать "подкачку" данных в прерывании по TXCOMP, то, почему-то, не отправляется уже вторая порция данных.

Например, обрабатывается запрос хоста GET_DESCRIPTOR_DEVICE:
1) по прерыванию от EP0 выгребаю запрос из FIFO
2) формирую дескриптор устройства
3) первые 8 байт дескриптора загружаю в FIFO и поднимаю TXPKTRDY
4) жду прерывания от TXCOMP - и оно приходит
5) сбрасываю TXCOMP
6) очередную порцию дескриптора загружаю в FIFO и поднимаю TXPKTRDY
и ничего не передается, хост ждет некоторое время и обрывает транзакцию IN.

Про необходимость правильной реакции на обрыв транзакции знаю.
Где могут быть грабли? Любые соображения приму с багодарностью.

PS. Обратите внимание, что в случае поллинга флага TXCOMP все работает как часы, поэтому обсуждать правильность реализации протокола, видимо, не имеет смысла.

[Serg_Sm]

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

1) по ENDBUSRESET сброс EP и т.п.;
2) Получаю запрос на дескриптор устройства;
3) Первые 8 байт дескриптора загружаю в FIFO и поднимаю TXPKTRDY, сбрасываю TXCOMP;
4) Жду TXCOMP, посылаю следующие 8 байт (поднимая TXPKTRDY), сбрасываю TXCOMP.
И вот здесь наблюдается затык...

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

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

[Serg_Sm]

Это классические грабли.
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).

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