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

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

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

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

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

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

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

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

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

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

Можно сделать хост на другом микроконтроллере (для тестирования девайса на LPC18xx на уровне эндпоинтов USB).

Контроллер USB в LPC18xx скорее всего похож на LPC43xx, но не похож на LPC17xx.

Скорее косяки в библиотеках NXP - они ужасно кривые. Кстати LPCUSBlib уже давным давно deprecated. А стек засунут в USBROM и LPCOpen умеет использовать только его.


Берем генертор псевдослучайных чисел. Сид в программе и проишвке один. Итоговая последовательность там и тут должна совпадать. В контроллере что-то делаем с полученными данными, например xor и отправляем назад. В программе проверяем что посчитанное и полученное одно и тоже.

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

Ну, методов проверки можно много придумать, весь вопрос - как это сделать? Т.е. как работать на ПК с конечными точками USB без использования стандартных классов.


Именно. Поэтому мне интересно - делал ли кто-нибудь Mass Storage с EP=512байт именно на LPC18xx.

Одно дело, если бы программа просто не работала. Но она же не работает только на части плат!
Беру за основу пример от NXP для отладочной платы с LPC1830 и SD-картой - там работает.
Переписал под отладку для своего устройства - работает.
Зашил в готовое изделие - работает.
Отдал на тестирование, там прошили 10 устройств - 5 работает, 5 нет. Причем не работают по-разному!

Не укажите где именно в LPCOpen есть возможность такой настройки?

Нужно сделать *.inf для конкретного вида/пида с драйвером winusb(k). И работать WinUsb_*.

Глюк забавный, неужто нет возможности взять устройство которое не работает и посмотреть что происоходит под отладкой?

Есть драйвера (под винду) позволяющие работать с эндпоинтами с уровня приложения. Я использую один из таких: CypressUSB (из состава "Cypress Suite USB"). Есть ещё libusb.
Как Вам уже объяснили: делаете inf-файл с нужными VID/PID для этого драйвера и дальше работаете через него (т.е. - через его библиотеку).
Даже можно и не писать ничего со стороны ПК: в составе "Cypress Suite USB" есть утилитки, позволяющие передавать кадры произвольных данных через нужные эндпоинты. Либо в окошке их набираете либо из файла.


Всё-таки: почему Вы подозреваете именно USB, а не работу с eMMC?



В LPC43xx именно bulk-передачи не использовал. Только control-передачи. Но с размером кадра до 2048 байт (разные размеры пробовал).

Файл LPCUSBlibConfig.h, дефайн USE_USB_ROM_STACK
Спасибо, буду смотреть
Здесь две проблемы:
1. МК в BGA-корпусе, JTAG не выведен. Т.е. подключаться надо к via под МК. Но это, в общем-то решаемо.
2. В готовом изделии запрограммированы OTP-биты. Т.е. сначала из SPI-флеши считывается загрузчик, который уже загружает мою программу по нужному адресу ОЗУ. Честно говоря, не знаю, получится ли при таком сценарии подключиться отладчиком.

Если в OTP JTAG не запрещён и если firmware сразу после старта не запрещает JTAG через спец. регистры периферии - получится.
У меня сейчас на LPC4370 именно так и работает. JTAG подключается без проблем, хоть есть прошивка в SPI-флеши, хоть код BootROM работает - без разницы.
Если всё-же будут проблемы, то boot-пинами или в OTP переключитесь на загрузку не с флешки, а с чего-нить другого.

Спасибо

1. Проблема исчезает при задании в дескрипторе размера EP=128 байт. Эта величина влияет исключительно на работу модуля USB.
2. Я сделал отладочный вывод в callback-функции обработки SCSI-команд, которая вызывается ядром USB. И в проблемном месте вывод информации не происходит. Т.е. до обработки команды (чтения/записи eMMC) дело даже не доходит.




Спасибо, буду изучать.
Только что посмотрел - программируются только BOOT-биты. Так что надежда есть

Вы про LPCUSBlib, я про LPCOpen.

Это вы себе здорово в ногу выстрелили. Кмк выводить отладку хоть как-то нужно везде. Даже если она в устройстве будет отключаться.

Ну так LPCUSBLib - стек USB, используемый в LPCOpen.
Как я понимаю, сначала была библиотека NXPUSB. Потом ее улучшили, обозвали LPCUSBLib и включили в состав LPCOpen.

Я это понимаю. Но в данном случае все случилось задолго до моего появления.

Следующим шагом вырезали из получившегося вариант использования без USB ROM'а.

Уговорили. :D Попробую еще раз воспользоваться ROM API.

Заодо сравните версию ботлоадера у рабочих и глючных процессоров.

Вообще, имея глючную плату нужно на ней проводить опыты. Чтобы вероятность ухватывания бага за хвост была максимальной. Обычно это делается удалением из проекта всего кода, выше BBB (MSC-SCSI). Тест только USB-стека и даже на чтение-запись секторов ставится пустышка.

Для чистоты эксперимента лучше иметь не один компьютерный HS-хост, а ещё на микроконтроллере.

Теоретически, бага в LPC для длинных пакетов может быть при отсутствии в нём (или кривом) USB-ФАПЧ (не USB-PLL). Тогда немного отличающиеся клоки хоста и девайса (или болтанка) будут ограничивать длину безошибочно принимаемых пакетов. Или может быть какой-то баг PLL. Я в LPC43xx видел странность, когда флаг стабилизации PLL постоянно устанавливался и сбрасывался при вполне допустимом диапазоне частоты. Иногда вообще не устанавливался, но клок был. Чистоту спектра не измерял никогда.

Я в LPC43xx после старта PLL, больше на его флаги не смотрю. Хотя наверное нужно сделать ISR. Но пока проблем в работе не наблюдается, а работаю давно и на разных частотах.
Для USB использую CGU.PLL0USB.

С горем пополам подпаял к нерабочей плате JTAG. А она взяла и заработала, даже без отладчика.
Проверил 4 другие имеющиеся нерабочие платы - две работают, как ни в чем не бывало.
Мистика какая-то.

Видимо, все-таки дело в частоте USB.. Точнее, в ее погрешности.

Тогда попробовать затактировать не от кварца, а от генератора.

Увы, вход GP_CLKIN не выведен на плате