LPC1820, проблема с USB Mass Storage, Часть плат не работает при размере EP = 512 байт Опции

[Harvester]

Добрый день.
Имеется устройство на LPC1820 + eMMC.
Устройство представляет собой USB Mass Storage Device ("флешка"), реализованное с использованием фирменной библиотеки LPCUSBlib (чисто программный вариант, без использования функций USB ROM).
Проблема в следующем: часть плат некорректно работают при размере конечных точек больше 128 байт. Некорректность заключается в том, что устройства, судя по снифферу, в какой-то момент перестают отвечать на USB-запросы чтения/записи. Причем этот момент может отличаться для разных устройств, но для каждого конкретного устройства он фиксирован (т.е. одни устройства "виснут" на первой же команде чтения, другие обрабатывают команду чтения нормально, но "виснут" при записи).

Программист, написавший программу, утверждал, что это недокументированный баг в контроллере, который компания NXP не хочет признавать. И указывал на строки, имеющиеся в исходниках использованной им версии библиотеки LPCUSBLib:

Код

/* Max In/Out Packet Size */
#define MSC_FS_MAX_PACKET  128
#define MSC_HS_MAX_PACKET  128 /* < 256 work */

У меня стоит задача реализовать работу со штатным размером EP (512 байт). Я взял последнюю версию библиотеки - проблема не ушла.
Понятно, что теперь мне только остается детально исследовать работу библиотеки и модуля USB - может это все-таки программная бяка?
Но вдруг кто-нибудь сталкивался с подобной ситуацией и решил ее?
Спасибо.

[jcxz]

Программист, написавший программу, утверждал, что это недокументированный баг в контроллере, который компания NXP не хочет признавать. И указывал на строки, имеющиеся в исходниках использованной им версии библиотеки LPCUSBLib:

Код

/* Max In/Out Packet Size */
#define MSC_FS_MAX_PACKET  128
#define MSC_HS_MAX_PACKET  128 /* < 256 work */

Интересно каким образом эти строки говорят о баге в контроллере???
Баг определённо в вашем программисте. Так как другие программисты работают с этими контроллерами и не жужжат.
На LPC17xx и LPC43xx делал много проектов с USB. Нигде с багами контроллера не сталкивался. Сомневаюсь, что в LPC18xx USB-периферия хуже чем в других семействах LPC.
Я всегда использовал для них USB-стеки из примеров IAR. Использовал bulk- и изохронные передачи - никаких проблем.
Да и определитесь вначале хотя-бы где точно у Вас проблема - с обменом по USB (контроллер там явно не при чём) или с чтением/записью eMMC.
Можно например сделать буфер в ОЗУ вместо eMMC и поработать с ним как с USB-диском.
Либо поработать напрямую с эндпоинтами - погонять данные в них / из них. Без MassStorage. Убедиться в корректности передач с разными размерами.

[Harvester]

Баг определённо в вашем программисте. Так как другие программисты работают с этими контроллерами и не жужжат.

Ну, я как бы тоже больше доверяю NXP, поэтому и решил попробовать исправить ситуацию.

Да и определитесь вначале хотя-бы где точно у Вас проблема - с обменом по USB (контроллер там явно не при чём) или с чтением/записью eMMC.

Проблема где-то в обработчике USB - при появлении проблемного запроса callback-функция обработки SCSI-команд не вызывается.

Я всегда использовал для них USB-стеки из примеров IAR. Использовал bulk- и изохронные передачи - никаких проблем.

Спасибо за подсказку, попробую.

Либо поработать напрямую с эндпоинтами - погонять данные в них / из них. Без MassStorage. Убедиться в корректности передач с разными размерами.

А как это сделать? Особенно со стороны ПК.

P.S. Посмотрел примеры IAR - именно этот стек и использовался предыдущим программистом. Файл mscuser.h:

Код

/* Max In/Out Packet Size */
#define MSC_FS_MAX_PACKET  64
#define MSC_HS_MAX_PACKET  224 /* < 256 work */

А Вы точно использовали bulk-передачи с размером конечной точки 512 байт?

Сообщение отредактировал Harvester - Aug 24 2016, 19:01