AT91RM9200 как "USB Device", нет ли "граблей"? Опции

[gerber]

Есть серийное изделие на базе процессора AT91RM9200. Процесс заливки прошивки в изделие организован через UDP (USB Device Port) следующим порядком:
- пока прошивки в плате нет (в терминале DBGU бегут буквы CCC), USB-устройство, которое появляется в Windows обслуживается атмеловским драйвером DFU. Приложение Win32 через этот драйвер заливает туда первичный загрузчик, который грузит в память уже основной софт для прошивки всех имеющихся на плате флэш-модулей;
- этот софт представляется системе, как USB device с двумя конечными точками (помимо нулевой) - Bulk OUT и Bulk IN с размером пакета 64 байта. Далее весь обмен идёт через эти endpoints.
В частности, для заливки флэшки туда передаётся довольно большой объём данных через Bulk OUT endpoint, постранично, по 528 байт. Приложение вызывает функцию WriteFile(...), драйвер разбивает эти передачи на пакеты по 64 байта (8х64 и последний пакет 16 байт).
Внутри ARM приём данных организован довольно примитивно, поллингом - крутится цикл опроса поочерёдно статусных битов AT91C_UDP_RX_DATA_BK0 и AT91C_UDP_RX_DATA_BK1, по мере возникновения этих событий выгребаются данные из FIFO, после чего соотв. бит сбрасывается.
Всё это работало и работает до сих пор. Но пришла новая партия плат, где в процессе передачи блока данных на Bulk OUT endpoint в какой-то момент (где-то в середине заливки) происходит сбой - в USB-снифере видна ошибка 0xC0000005 - Device not responding, соответственно, WriteFile(...) возвращает ошибку. Со стороны ARM-ового приложения видно, что пакеты от хоста перестали поступать.
Осциллографом смотрел сигналы на DM,DP линиях - не отличаются визуально от тех плат, где сбоя не происходит. Ещё попробовал поменять между ними кварцевые резонаторы 12 МГц - проблема остаётся там, где и была.
Errata в части UDP-подсистемы RM9200 чиста. Схема подключения UDP к хосту сделано точь-в точь по даташиту.
Что ещё можно посмотреть и попробовать для выявления и локализации проблемы ? Где могут теряться пакеты ?
Если проблема в софте - то в чём она ? Наиболее вероятная версия - неуспевание выгрести из FIFO со стороны ARMa - в этом случае действительно посылается NACK. Но там негде возникнуть задержке - бесконечный цикл, который только и занимается тем, что опрашивает статус и выгребает данные...

Сообщение отредактировал gerber - Oct 8 2012, 09:19