Имеется LPC1758 на нём USB-device-стек взятый из примеров IAR для LPC17x. На LPC имеется ПО (сервер), передающее данные на PC через изохронную точку. На PC имеется ПО (клиент), принимающее данные через драйвер CyUSB.
Так вот, при работе CyUSB на winXP 32бит иногда (предположительно - при большой загрузке CPU) возникают потери пачек кадров. Даже собственно и не при очень большой загрузке CPU, но всегда наблюдается данный баг например при свёртывании/развёртывании любого окна на PC.
При работе CyUSB под другими виндами (и 32 и 64 бит) такой проблемы нет.
Также при работе другого устройства на другом процессоре и с другим USB-стеком (совершенно другое железо USB-контроллера) с данным клиентом проблем не возникает ни под какими виндами.

Подозреваю, что баг кроется в CyUSB, но почему он проявляется только при работе NXP-ного стека на LPC и не проявляется с другим контроллером???
Кто-нить сталкивался с подобными проблемами при работе USB-device-стека NXP из примеров IAR?

В стеке от ИАР когда я этим занимался я нашел парочку ошибок, связанных с НЕ обработкой нештатных ситуаций. Там в большем switch что-то не так было, и все команды валились в правильную ветку. Это было лет 5 назад, с тех пор я этот стэк не ковырял, свой делал.
Не знаю исправили они это или нет, но поглядите разбор входящих пакетов.

Ну и опять же можно поглядеть обмен на шине и посмотреть что там пришло и на что не ответил контроллер. Наверняка какой то нак не обрабатывается...

Пакеты по control-endpoint обрабатываются нормально. Проблема с изохронными IN-кадрами (от контроллера к PC).


Эх! если-б у меня был анализатор шины USB!
На стороне контроллера-то всё прекрасно - кадры отправляются все, никаких посторонних событий от шины не видно.
Когда на PC происходит критическая ситуация (сворачивание/разворачивание окна), на контроллере тишь да гладь - никаких изменений.
Даже джиттер вызовов моей функции отправки кадров от стека не превышает 30мкс и не зависит от наличия или отсутствия критического события на стороне PC.

А менять что-нибудь на стороне PC пробовали? Очередь запросов увеличить?

Конечно. И глубину очереди и кол-во пакетов в запросе. И приоритет потока: TIME_CRITICAL и всякие критические секции- блокировки убирал, что только ни делал.
Дело-то в том, что отключаю это устройство, подключаю другое (со своим самописным стеком) и всё прекрасно работает.
Запускал два клиента, параллельно работали с двумя этими устройствами - сворачиваю/разворачиваю любое постороннее окно - в одном клиенте потери почти всегда есть, в другом - никогда.
По USB-хабам тоже переставлял их местами.