Не могу разобраться с проблемой определения девайса после suspend.
событие resume отлавливается, но сам контроллер не сообщает драйверу о готовности возобновить передачу.
В качестве драйвера использую Thesycon.
В качестве контроллера LPC2368
В качестве управляющей программы - пример от tnkernel

Логическим анализатором засканил вариант отработки resume на JLink, и тестируемого устройства.
При resume на D+ появляется лог 0 на 1ms, после чего происходит обмен и снова в подтверждение D+ становиться в лог 0 на 1ms.
В моем случае подтверждения не получается.

Аналогичная реакция происходит и при подключении устройства к USB но в этом случае подтверждение есть.

Проверяю следующим образом, в device manager Windows отключаю драйвер (при этом ловим suspend) а после включаю,
отлавливаю resume но далее контроллер USB не выдает подтверждение, и процесс выдает ошибку.
Если в момент после suspend ресетнуть контроллер, то все проходит нормально, и драйвер активируется без проблем.

Лог событий из demo приложения от Thesycon:
вставляем

отключаем драйвер

задествуем драйвер после ресета программы

если не делать сброс программы то:

после чего в состоянии устройства USBIO появляется ошибка:
"Запуск этого устройства невозможен. (Код 10)"
проверял как на BUS Powered так и на Self Powered, разницы нет.
Подскажите в каком направлении двигаться, как отловить проблему, чем засканить обмен более детально, какие варианты попробовать ?

Много раз боролся с этой проблемой на разных МК. Всегда использовал цифровой осиллограф, синхронизировал его по заданному событию и рассматривал момент пробуждения. Вариантов масса. Но чаще всего я так или иначе неправильно формировал временную диаграмму Upstream Resume. В случае Remote Wakeup все было гораздо проще. Но, опять же, помогает осциллограф, а также вдумчивое чтение даташита и часто эрраты (!). Последний раз некорректное пробуждение было вызвано тем, что после ухода МК ARM9 в Suspend разрушались данные в ИС динамической памяти. Отлавливал неделю, но отловил же. Удачи ...
P.S. В качестве подопытного кролика очень удобно использовать USB - мышку или клавиатуру. Ценность их в том, что тут можно как захватить внешний Upstream Resume, так и в любой момент сгенерировать свой собственный Remote Wakeup ...

Сообщение отредактировал kovigor - Jan 17 2011, 20:01

насколько я себе думал, то пробуждение возложено на встроенный контроллер, и все диаграммы он должен формировать аппаратно, без участия написанного кода. Пользовательское ПО должно обеспечить снижение энергопотребления. Или я ошибаюсь ?
Проблема в том что что-то в модуле USB происходит такое, из за чего он виснет. Но, по этому поводу в даташите никаких намеков. suspend описан только как событие, и никаких рекомендаций или последовательностей действий я не нашел.
Errata тоже молчит по этому поводу.

Да ну, какой там. Чего стоят одни только прерывания по Resume/Wakeup, которые контроллер способен генерировать. И вообще, программной обработки там предостаточно. Виснет не сам USB движок, виснет ваше ПО. А вот почему - вопрос. Например, потому, что некорректно обрабатывается прерывание(я). Или вы перед усыплением понижаете тактовую частоту, засыпаете с пониженной частотой и с ней же просыпаетесь, и в результате продолжаете работать, считая, что частота не пониженная, а обычная, или вообще выключаете тактирование USB перед засыпанием, или выключаете одну из PLL. Причин тысяча. Какая ваша ? Это вы должны выяснить сами ...

Сообщение отредактировал kovigor - Jan 17 2011, 22:35

Решил пойти другим путем.
1. скачал с сайта производителя тут пример AN10759 USB bootloader (LPC23xx) (v.1.0, 2008-10-14)
Там контроллер выдает себя за Mass Storage и появляется в винде в виде диска с файлом firmware.
2. Залил его в мой контроллер.
И собственно все те же проблемы. Находиться диск, на нем файл, винда не ругается, применяет стандартный драйвер.
Но попытка воспроизвести отключение драйвера с последующей активацией вызывает точно такие же проблемы.

Сами функции обработки suspend и Resume есть, но они пустые. Собственно как и у меня. Никаких действий с вводом контроллера в спящий режим не производиться.
Может в этом и проблема ?
Тогда вопрос, как правильно это делать ? В документации на контроллер никаких упоминаний про рекомендуемые действия после suspend и resume я не нашел. Может не там искал, или не так понял...

Там надо воздействовать как минимум на регистр PCON. Вот обработчик прерывания, извлеченный из одного из моих проектов для LPC214x. Именно он обрабатывает Suspend и переводит МК в соотв. режим. Весь проект выложить, к сожалению, не могу. Если что будет непонятно - спросите ...

http://zalil.ru/30373924

P.S. Игрался с HID - примером от Кейла. Там Suspend работает некорректно. Было это давно, деталей не помню ...

P.P.S.

Люди просят весь проект. Вот он. Пароль сообщу в ответе на личное сообщение ...

http://zalil.ru/30376114

Сообщение отредактировал kovigor - Jan 21 2011, 09:39

Большое Спасибо, за предоставленный код, основную идею понял, но на LPC23xx все оказалось несколько иначе, возможно я опять все попутал ...
Итак имеем бит USB_NEED_CLK который должен сброситься после 2ms как только активность на шине прекратиться.
Once USB_NEED_CLK becomes one, it it resets to zero 5 ms after the last packet has been
received/sent, or 2 ms after the Suspend Change (SUS_CH) interrupt has occurred.
В другом месте говориться о том что состояние биты DEV_CLK_EN и AHB_CLK_EN должны быть 0 0 и только после этого USB_NEED_CLK будет равен нулю.
After entering the suspend state with DEV_CLK_EN and AHB_CLK_EN cleared, the
DEV_CLK_ON and AHB_CLK_ON will be cleared when the corresponding clock turns off.
When both bits are zero, USB_NEED_CLK will be low, indicating that the chip can be put
into Power Down mode by writing to the PCON register.
На самом деле USB_NEED_CLK всегда 1.
Errata утверждает что данная проблема имела место в ревизии -, а у меня B. Но предложенный ими вариант решения проблемы испробовал.
After setting the PCUSB bit in PCONP (located at 0xE01F C0C4), write 0x1 to address
0xFFE0C008. The USB_NEED_CLK signal will now function correctly. Writing to address
0xFFE0C008 only needs to be done once after each chip reset.
чудо произошло, но не надолго. При таком подходе контроллер абсолютно никак не реагирует на то, чтобы ответить на запрос шины, до дискриптора даже не доходит. Хотя если бродить JTAG-ом то все находиться как нужно, при сбросе контроллера и запуске отладки.
Тогда сделал следущее:

при этом во первых....

срабатывает только при отладке JTAG
- срабатывает всегда (смотрю по потребляемому току), но проснуться контроллер уже не может.

Допустим мы пропустим все режимы сна, а просто после запуска и определения устройства остановимся на suspend, выключим а затем включим драйвер, и продолжим выполнение программы.
По логике код должен продолжить функционирование как ни в чем не бывало, но проблема остается все в той же форме.

привожу результаты последних исследований.

после этого ядро USB отваливается, J-LINK показавает в области памяти USB 0xAAAAAAAA
т.о. действия описанные в Errata можно расценивать как дезу, ну или все таки оно работает на единственной ревизии "-"
найти которую уже не получиться.
т.о. имеем проблему с тем, что USB_NEED_CLK никогда не становиться равным 0.
похожая проблема поднималась тут и тут и осталась без решения.
Кроме предложенного вырианта от NXP, был проверен пакет code.bundle.lpc23xx.lpc24xx.uvision.zip
в котором вроде как, suspend и resume обрабатываются.
результат не удивил, при suspend происходит зависание на цикле ожидания USB_NEED_CLK;
непонятно как это работало у человека, который писал этот код

Есть ли у кого из присутсвующих возможность проверить данный код на платах ENG_BOARD_LPC24XX
или KEIL_BOARD_LPC23XX или SK-LPC2378 (c мелкими изменениями в инициализации) ?

Есть ли адрес службы поддержки NXP (не то что на сайте, а тот с которого отвечают ), или какие другие предложения по поиску решения ?

Я с LPC23xx не работал, посему на роль носителя абсолютной истины не претендую. Но все же. Вчитайтесь в описание бита "AP_CLK" в п.9.3 описания на LPC214x (UM10139):

9.3 Set Mode (Command: 0xF3, Data: write 1 byte)

AP_CLK = 0: usb_needclk is functional; 48 MHz clock can be stopped when
the device enters suspend state.
AP_CLK = 1: usb_needclk always have the value 1. 48 MHz clock cannot be
stopped in case when the device enters suspend state.

Вообще, в чем проблема ? В том, что вы не знаете, что на шине пропали маркеры SOF и вы не знаете, когда переходить в Suspend ?

в моем случае AP_CLK = 0, т.е. я должен дождаться пока usb_needclk не сброситься, и потом могу убрать тактирование с USB модуля. SOF пропадает, это я вижу на осциллографе, но вот usb_needclk продолжает быть 1. и соответственно дальше ничего не возможно делать.
Получается, что я не вижу аппаратно пропадание SOF.

Хорошо. А если не обращать на этот бит внимания, а просто, например, раз в миллисекунду в обработчике любого подходящего прерывания проверять USBDevIntSt.DEV_STAT ? Этот бит укажет вам на "USB suspend change". Дальше подаете команду: Get Device Status (Command: 0xFE, Data: read 1 byte). Она выдаст вам, пропали маркеры на шине или не пропали (см. Table230, описание битов SUS и SUS_CH). Дальше все просто, и usb_needclk оказывается не нужным. Я, правда, так не делал, поэтому ничего не обещаю ...

Само прерывание по suspend() работает, с FE попробую, но ... ведь тот же usb_needclk используется для просыпания контроллера, и соответственно он уже не проснется.

Ну что я могу сказать ? Заведите линию D+ или D- на вход внешнего прерывания МК, можно через КМОП - повторитель вроде SN74LVC1G07. На 12МБит все должно работать. У меня, во всяком случае, работало и работает. Т.е., вы обнаружили, что маркеры SOF пропали. Чудесно. Теперь линия D+ всегда стоит в "1". Настраиваем внешнее прерывание на возникновение по спадающему фронту сигнала на входе прерывания МК и засыпаем, и спим, сколько угодно. Как только по шине пройдет первый маркер, у вас на входе прерывания напряжение упадет до нуля, произойдет прерывание и МК проснется. Думаю, это единственный способ решить вашу проблему ...

Сообщение отредактировал kovigor - Jan 27 2011, 10:34

Была такая мысль, но я пока её отгонял. Написал в support и на форум NXP. Подождем результатов, а пока попробую реализовать по вашей схеме.

Моя схема работает на LPC214x. На LPC23xx не пробовал и ничего не обещаю ...