Перейти к содержанию
    

Потеря USB-пакетов (LPC1758)

Имеется 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Конечно. И глубину очереди и кол-во пакетов в запросе. И приоритет потока: TIME_CRITICAL и всякие критические секции- блокировки убирал, что только ни делал.

Дело-то в том, что отключаю это устройство, подключаю другое (со своим самописным стеком) и всё прекрасно работает.

Запускал два клиента, параллельно работали с двумя этими устройствами - сворачиваю/разворачиваю любое постороннее окно - в одном клиенте потери почти всегда есть, в другом - никогда.

По USB-хабам тоже переставлял их местами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...