Доброго дня!

Столкнулся со следующей проблемой - слегка подправленный для работы с USB-принтером UsbHostLite для LPC1768 преподнес сюрприз. Довольно обширное число принтеров работает нормально (если не GDI, конечно). Но вот подключили клиенты HP P2055, а он просто виснет в процедуре энумерации. Никаких идей нет, разве что предположение о том, что принтер USB2.0 HighSpeed, что LPC1768 точно не поддерживает. И вообще, судя по тому, что написано в интернете, OHCI, реализованная в хосте LPC1768, не имеет никакого отношения к USB2.0. По принтерам HP информации толком не найти, они у них все исключительно USB2.0 уже тысячу лет, но при этом совершенно точно все печаталось с струйником HP5550 и более старым лазером P2015. В чем вообще может быть корень проблемы? Есть ли USB-устройства, которые принципиально не работают с хостами USB1.1, которым по сути, как я понял, и является LPC1768 несмотря на все заверения производителя? В чем искать корень проблемы - в стеке UsbHostLite или все-таки в принтере?

Спасибо за возможные ответы!

Стандарт допускает существование HS-устройств, не работающих в FS. Только есть одно "но" - энумерацию в FS они должны проходить в любом случае.


На 99% в стеке. Для очистки совести можно просто воткнуть принтер в FS-порт на ПК для проверки.

Обязана энумерация работать на FS, как минимум. И принтер почти наверняка будет работать на FS. Варианта два. Первый - модифицировать ваш проект так, чтобы он по UART выдавал внешней машине все запросы, которые МК шлет принтеру в процессе энумерации и все ответы принтера. Второй - использовать аппаратный сниффер USB, если таковой у вас есть ...

Это хорошая идея. Но, думаю, что все-таки нужно на живом принтере экспериментировать, а его нет. Почему есть сомнения в железе - пробовали вчера в сервисном центре P2035, на нем все работает, пробовали массу других - тоже работает, энумерация по крайней мере. Это пока единственный экземпляр, который вызвал подобные проблемы. Есть подозрение, что может быть что-то с током потребляемым от порта, у нас там стоит LM3525 в качестве супервизора тока.

А, так это на одном таком принтере, другие той же модели работают нормально ? Тогда он может быть просто неисправным ...

Да, есть такие подозрения. Наверное, стоит посмотреть, как UsbHostLite реагирует на всякие непредсказуемые ситуации, тут вроде бы писали, что отработки их там нет вообще...

ЧТобы не вводить в заблуждение сообщество, отпишу. Все нормально с принтерами, просто в UsbHostLite не реализован разбор композитных устройств, коими стали многие принтеры. Проблема была, собственно в этом. Как только получили принтер и распарсили ответ - все стало очевидно.

может в этом дело
A Solution to the dribble bit problem для USB host controller hangs on a dribble bit (LPC1769/68/66/65 only)
3.12 USB.1: USB host controller hangs on a dribble bit (LPC1769/68/66/65
only)
Introduction:
Full-/low-speed signaling uses bit stuffing throughout the packet without exception. If the
receiver sees seven consecutive ones anywhere in the packet, then a bit stuffing error has
occurred and the packet should be ignored.
The time interval just before an EOP is a special case. The last data bit before the EOP
can become stretched by hub switching skews. This is known as dribble and can lead to a
situation where dribble introduces a sixth bit that does not require a bit stuff. Therefore,
the receiver must accept a packet for which there are up to six full bit times at the port with
no transitions prior to the EOP.
Problem:
The USB host controller will hang indefinitely if it sees a dribble bit on the USB bus. It will
hang the first time a dribble bit is seen. Once it is in this state there is no recovery other
than a hard chip reset. This problem has no effect on the USB device controller.
Work-around:
None.