Непонятки с 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 все работает как часы, поэтому обсуждать правильность реализации протокола, видимо, не имеет смысла.

[KAlex]

5) сбрасываю TXCOMP

Попробуй так
if (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP) {
pUdp->UDP_CSR[0] &= ~(AT91C_UDP_TXCOMP);
while (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP);
}

[sgrig]

Попробуй так
if (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP) {
pUdp->UDP_CSR[0] &= ~(AT91C_UDP_TXCOMP);
while (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP);
}

Так и делаю, примеры я разобрал по "косточкам" и все попробовал. Похоже, я чего-то не понимаю.
Кстати, такая же "подкачка" для TWI работает без проблем.

[KAlex]

Вот кусок рабочего кода. Никаких прерываний. AT91F_UDP_IsConfigured вызывается постоянно из основного цикла.
__arm static void AT91F_USB_SendData(AT91PS_UDP pUdp, const char *pData, u_int length){
u_int cpt = 0;
AT91_REG csr;
do { cpt = MIN(length, 8);
length -= cpt;
while (pUdp->UDP_CSR[0] & AT91C_UDP_TXPKTRDY)
if ( pUdp->UDP_ISR & AT91C_UDP_RXSUSP ) return;
while (cpt--) pUdp->UDP_FDR[0] = *pData++;
if (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP) {
pUdp->UDP_CSR[0] &= ~(AT91C_UDP_TXCOMP);
while (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP);
}
pUdp->UDP_CSR[0] |= AT91C_UDP_TXPKTRDY;
do {
csr = pUdp->UDP_CSR[0];
// Data IN stage has been stopped by a status OUT
if (csr & AT91C_UDP_RX_DATA_BK0) {
pUdp->UDP_CSR[0] &= ~(AT91C_UDP_RX_DATA_BK0);
return;
}
} while ( !(csr & AT91C_UDP_TXCOMP) );
} while (length);
if (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP) {
pUdp->UDP_CSR[0] &= ~(AT91C_UDP_TXCOMP);
while (pUdp->UDP_CSR[0] & AT91C_UDP_TXCOMP);
}
}

__arm void AT91F_USB_SendStall(AT91PS_UDP pUdp)
{
pUdp->UDP_CSR[0] |= AT91C_UDP_FORCESTALL;
while ( !(pUdp->UDP_CSR[0] & AT91C_UDP_ISOERROR) );
pUdp->UDP_CSR[0] &= ~(AT91C_UDP_FORCESTALL | AT91C_UDP_ISOERROR);
AT91F_UDP_ResetEp ( pUdp, 1);
while (pUdp->UDP_CSR[0] & (AT91C_UDP_FORCESTALL | AT91C_UDP_ISOERROR));
}

__arm static void AT91F_HID_Enumerate(AT91PS_HID pHid)
{
AT91PS_UDP pUDP = pHid->pUdp;
uc08 bmRequestType, bRequest;
ushort wValue, wIndex, wLength, wStatus;

if ( !(pUDP->UDP_CSR[0] & AT91C_UDP_RXSETUP) ) return;

bmRequestType = pUDP->UDP_FDR[0];
bRequest = pUDP->UDP_FDR[0];
wValue = (pUDP->UDP_FDR[0] & 0xFF);
wValue |= (pUDP->UDP_FDR[0] << 8);
wIndex = (pUDP->UDP_FDR[0] & 0xFF);
wIndex |= (pUDP->UDP_FDR[0] << 8);
wLength = (pUDP->UDP_FDR[0] & 0xFF);
wLength |= (pUDP->UDP_FDR[0] << 8);

if (bmRequestType & 0x80) {
pUDP->UDP_CSR[0] |= AT91C_UDP_DIR;
while ( !(pUDP->UDP_CSR[0] & AT91C_UDP_DIR) );
}
pUDP->UDP_CSR[0] &= ~AT91C_UDP_RXSETUP;
while ( (pUDP->UDP_CSR[0] & AT91C_UDP_RXSETUP) );

// Handle supported standard device request Cf Table 9-3 in USB specification Rev 1.1
switch ((bRequest << 8) | bmRequestType) {
case STD_GET_DESCRIPTOR:
run = 0;
if (wValue == 0x100) // Return Device Descriptor
AT91F_USB_SendData(pUDP, devDescriptor, MIN(sizeof(devDescriptor), wLength));
else if (wValue == 0x200) // Return Configuration Descriptor
AT91F_USB_SendData(pUDP, cfgDescriptor, MIN(sizeof(cfgDescriptor), wLength));
else if (wValue == 0x300) // Return Configuration Descriptor
AT91F_USB_SendData(pUDP, String0, MIN(sizeof(String0), wLength));
else if (wValue == 0x302) // Return Configuration Descriptor
AT91F_USB_SendData(pUDP, String1, MIN(sizeof(String1), wLength));
else if (wValue == 0x303) // Return Configuration Descriptor
AT91F_USB_SendData(pUDP, String1, MIN(sizeof(String1), wLength));
else
AT91F_USB_SendStall(pUDP);
break;
... поскипано
__arm static uc08 AT91F_UDP_IsConfigured(AT91PS_HID pHid)
{
AT91PS_UDP pUDP = pHid->pUdp;
AT91_REG isr = pUDP->UDP_ISR;

if (isr & AT91C_UDP_ENDBUSRES) {
pUDP->UDP_ICR = AT91C_UDP_ENDBUSRES;
// reset all endpoints
pUDP->UDP_RSTEP = (unsigned int) -1;
pUDP->UDP_RSTEP = 0;
// Enable the function
pUDP->UDP_FADDR = AT91C_UDP_FEN;
// Configure endpoint 0
pUDP->UDP_CSR[0] = (AT91C_UDP_EPEDS | AT91C_UDP_EPTYPE_CTRL);
}
else if (isr & AT91C_UDP_EPINT0) {
pUDP->UDP_ICR = AT91C_UDP_EPINT0;
AT91F_HID_Enumerate(pHid);
}
...поскипано

[sgrig]

Вот кусок рабочего кода. Никаких прерываний. AT91F_UDP_IsConfigured вызывается постоянно из основного цикла.
...................................

Вопрос как раз и состоял в том, как это все заставить работать ПО ПРЕРЫВАНИЯМ.
Без прерываний проблем нет, но это же вариант совсем пионерский.

[KAlex]

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

О! А проверка TXPKTRDY где?

[sgrig]

О! А проверка TXPKTRDY где?

А вот с этого места, пожалуйста, подробнее. Зачем его проверять? Ведь TXCOMP устанавливается после падения TXPKTRDY.

[KAlex]

Ведь TXCOMP устанавливается после падения TXPKTRDY.

По лигике вещей, так оно и должно быть. Но в даташите об этом ни слова:
>>Данный флаг используется для генерации транзакции "Ввод данных" (в направлении устройство->>хост). Программа устройства проверяет возможность записи данных в FIFO путем оценки состояния >>TXPKTRDY, который должен быть равен нулю. Передача в FIFO выполняется путем записи в регистр >>UDP_ FDRx. Сразу после передачи данных в FIFO программа должна уведомить об этом USB->>устройство путем установки бита TXPKTRDY. После этого можно начинать транзакцию USB. TXCOMP >>устанавливается сразу после приема данных хостом.
И по cкольку у нас поток "управление", в котором при детекции ошибки повторение автоматическое,
то ХЗ, что первым падает и устанавливается.

[sgrig]

Попробовал и это. Не помогло. Пойду напьюсь, может просветление наступит

[KAlex]

Попробовал и это. Не помогло. Пойду напьюсь, может просветление наступит

Тоже иногда надо. А то

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

Про RXSETUP не забыл?

[sgrig]

Тоже иногда надо. А то
Про RXSETUP не забыл?

Конечно нет. Я же говорю, если TXCOMP ждать в цикле, то все работает. Если в прерывании, то кирдык.

[Calculator]

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

Насколько я помню, сначала нужно поднять TXPKTRDY, а уже потом сбросить TXCOMP

[sgrig]

Насколько я помню, сначала нужно поднять TXPKTRDY, а уже потом сбросить TXCOMP

Делал и так, те же balls, side view. Похоже, косяк в кристалле: биты TXCOMP и STALLSENT не вызывают прерывание EP0INT, при этом RXSETUP и RX_DATA_BK работают, как описано в DS.

[YKonstantin]

3) первые 8 байт дескриптора загружаю в FIFO и поднимаю TXPKTRDY
6) очередную порцию дескриптора загружаю в FIFO и поднимаю TXPKTRDY

А какой размер второго пакета?
Случайно не 8, и к тому же это последний пакет?

[sgrig]

А какой размер второго пакета?
Случайно не 8, и к тому же это последний пакет?

Нет, эту фишку я тоже знаю. Там действительно косяк с прерыванием.

[YKonstantin]

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

[sgrig]

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

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

[YKonstantin]

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

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

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

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

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

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

[sgrig]

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

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

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

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

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

[YKonstantin]

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

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

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

[sgrig]

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

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

[YKonstantin]

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

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

[sgrig]

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

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

[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).

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

[aaarrr]

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

[Serg_Sm]

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

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

[aaarrr]

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

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

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

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

[Serg_Sm]

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


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

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

[Serg_Sm]

Так все-таки, подскажите - запрос GetDeviceDescriptor после сброса, есть система запрашивающая 18 байт и честно получающая все 18 байт, эта же система может запросить 8 байт и ждет 8 байт. Тут всё нормально. Но есть система запрашивающая 18 байт, которая после получения 8 байт разрывает обмен и тут же посылает следующий SETUP пакет. Вот здесь и начинается самое интересное - если до разрыва контроллер успел забить очередь следующими 8 байтами, то при получении SETUP получаем тотальный сбой с невозможностью что либо принять/передать по USB, если же очередь заполнить не успели, то всё проходит нормально.
Как на такое реагировать?

[misyachniy]

Так все-таки, подскажите - запрос GetDeviceDescriptor после сброса, есть система запрашивающая 18 байт и честно получающая все 18 байт, эта же система может запросить 8 байт и ждет 8 байт. Тут всё нормально. Но есть система запрашивающая 18 байт, которая после получения 8 байт разрывает обмен и тут же посылает следующий SETUP пакет. Вот здесь и начинается самое интересное - если до разрыва контроллер успел забить очередь следующими 8 байтами, то при получении SETUP получаем тотальный сбой с невозможностью что либо принять/передать по USB, если же очередь заполнить не успели, то всё проходит нормально.
Как на такое реагировать?

Получили RESET - очищайте все передачи.
И ждите SETUP.

[Serg_Sm]

Получили RESET - очищайте все передачи.
И ждите SETUP.

RESET получен, SETUP с запросом GetDeviceDescriptor 18 байт length. После 8 байт передачи идет следующий SETUP без RESET и всё. В старых системах (на XP) после такого шел RESET, а на 8-ке SETUP. RESET убрали для повышения скорости.

[misyachniy]

RESET получен, SETUP с запросом GetDeviceDescriptor 18 байт length. После 8 байт передачи идет следующий SETUP без RESET и всё. В старых системах (на XP) после такого шел RESET, а на 8-ке SETUP. RESET убрали для повышения скорости.

В чем вопрос?
Получили RESET - все конечные точки в режим STALL.
Не получили - продолжаете передачу.
Я с SAM7S64 уже лет 5 не работаю.
Но точно помню, что вопросов не возникало.

[Serg_Sm]

В чем вопрос?
Получили RESET - все конечные точки в режим STALL.
Не получили - продолжаете передачу.
Я с SAM7S64 уже лет 5 не работаю.
Но точно помню, что вопросов не возникало.

RESET уже прошел - обработали и забыли. Далее идет обмен, вот картинка для наглядности:


8 байт отослали хосту, затем он рвет связь (что не удается отследить). В это время в очередь загружается последующие 8 байт и с приходом следующего SETUP получаем невосстанавливаемый сбой.

[misyachniy]

RESET уже прошел - обработали и забыли. Далее идет обмен, вот картинка для наглядности:


8 байт отослали хосту, затем он рвет связь (что не удается отследить). В это время в очередь загружается последующие 8 байт и с приходом следующего SETUP получаем невосстанавливаемый сбой.

Не могу понять по картинке, где ошибка?
Ищите у себя в программе.

Вот моих два старых проекта на SAM7S

http://njnmnp.narod.ru/proj/usb_bulk_sam7/usb_bulk_sam7.html
http://njnmnp.narod.ru/proj/prog16/prog16.html

[Serg_Sm]

Не могу понять по картинке, где ошибка?
Ищите у себя в программе.

Вот моих два старых проекта на SAM7S

http://njnmnp.narod.ru/proj/usb_bulk_sam7/usb_bulk_sam7.html
http://njnmnp.narod.ru/proj/prog16/prog16.html

Ошибка в том, что запрос SetAddress не проходит - SETUP пакет не принимается корректно.
Что касается двух ссылок с проектами, то оба проекта не работают под искомой системой (в Windows XP на другой машине работают).
Отличие только в том, что возвращается STALL на запрос SetAddress (в моем случае идет безответный сбой). Естественно после этого устройство не работоспособно.

PS: Может у кого есть точно рабочий проект с USB на SAM7S64? Проверенный на 8-ке и без больших тормозящих навесок (с задержками более 1мс между обработкой прерываний скорее всего заработает), нужен только процесс энумерации. Хоть бинарник киньте - попробую проверить.

[Serg_Sm]

Всё, вроде разобрался)) Теперь работает везде где проверял с тестами и так (XP, 8.1 и 10).
Причина была во флаге TXCOMP. У меня использовался переделанный пример из под FREERTOS, и есть там такая фича - сброс сразу кучи прерываний в обработчике (осталась у меня в проекте). А TXCOMP был задефайнен в эту кучу. Т.е. TXCOMP сбрасывался еще до обработки прерывания на него. Соответственно сделал сброс TXCOMP только в одном месте после полной обработки соответствующего прерывания - проблема ушла.