suspend & resume USB LPC23xx, зависание USB контроллера Опции

[andrvisht]

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

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

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

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

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

Код

OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)
OnDeviceChange message: 00008004 (DBT_DEVICEREMOVECOMPLETE)
The USB device \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4} has been removed.
OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)
OnDeviceChange message: 00008000 (DBT_DEVICEARRIVAL)
A new USB device has been plugged in and is now available.
Device path is: \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4}.
OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)

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

Код

OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)
OnDeviceChange message: 00008004 (DBT_DEVICEREMOVECOMPLETE)
The USB device \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4} has been removed.

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

Код

OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)
OnDeviceChange message: 00008000 (DBT_DEVICEARRIVAL)
A new USB device has been plugged in and is now available.
Device path is: \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4}.
OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)

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

Код

OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)
и через секунду еще раз
OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED)

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

[andrvisht]

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

*((int*)0xFFE0C008) = 1;

после этого ядро 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 (не то что на сайте, а тот с которого отвечают ), или какие другие предложения по поиску решения ?

[kovigor]

или какие другие предложения по поиску решения ?

Я с 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 ?

[andrvisht]

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

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

[kovigor]

в моем случае 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 оказывается не нужным. Я, правда, так не делал, поэтому ничего не обещаю ...

[andrvisht]

Хорошо. А если не обращать на этот бит внимания, а просто, например, раз в миллисекунду в обработчике любого подходящего прерывания проверять 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 используется для просыпания контроллера, и соответственно он уже не проснется.

[kovigor]

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

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

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

[andrvisht]

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

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

[kovigor]

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

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

[andrvisht]

За обещанный промежуток в 5 рабочих дней техподдрежка NXP так и не ответила.
Видимо вопрос не укладывается в стандартные ответы
На форуме NXP аналогичная ситуация ...

По предложенной методике все получилось. Причем в LPC23xx есть возможность настроить на просыпание GPIO0, что позволило обойтись без внешних повторителей.

Код

void  suspend(void)
{
     USBClkCtrl = 0x00;
     while ((USBClkSt & 0x12) != 0x00);
     INTWAKE = 1u<<7;
     IO0_INT_EN_F = 1u<<29;
     IO0_INT_CLR = 1<<29;
     PCON = 0x06; // Power Down
     PLL_init();
}
void  resume(void)
{
     INTWAKE = 0;
     USBClkCtrl = 0x12;
     while ((USBClkSt & 0x12) != 0x12);
}

Поиск путей снижения тока потребления привел к следующим изысканиям, может кому то это пригодится:
1. Если USB модуль включен в PCONP, и Power Down происходит не по шине USB, то сам модуль потребляет ~1 мА.
При этом, его можно отключить с помощью PINSEL настроив D+ и D- как GPIO.
2. При получении suspend по USB 1мА модулем не потребляется, но можно отключить D+ и D- при этом USB продолжает функционировать и дальше.
3. Сработка прерывания по GPIO0 происходит даже при том, что нога выбрана как USB+.
4. Выключение DEV_CLK и AHB_CLK впринципе не требуется, но логика подсказывает что выключать все таки правильнее.
5. Cигнал USB_POW о наличии подключения USB разьема потребляет 100мкА (подаю через 10к) по понятным причинам 5 В USB и 3.3В контроллера. И вот тут как нельзя кстати подходит предложенный буфер.
6. в Power Down по описанию должна сбрасываться PLL и USB_DIV (в отличие от LPC21xx тут частота береться от основной PLL), но на практике получается что PLL и делитель остаются в настроенном состоянии. Хотя осциллом вижу прекращение генерации на кварце.

Вот с 6 пунктом вопрос, то ли я опять чего то гдето не дочитал, то ли глюк чипа, то ли просто мне так везет, но когда нибудь PLL все таки отключиться .. ?
И еще вопрос, а что привело к использованию такого рода схемы на LPC124x, ведь там то проблем с USB_NEED_CLK нет ?

[kovigor]

По предложенной методике все получилось.
И еще вопрос, а что привело к использованию такого рода схемы на LPC124x, ведь там то проблем с USB_NEED_CLK нет ?

По той, что я предложил, с просыпанием по первому же SOF, пришедшему по принудительно заведенной на GPIO линии D+ (D-) ?

А я эту схему в LPC214x не использовал. Я ее предложил специально вам. На LPC214x все реализуется штатными средствами МК. Я может не так выразился, но в своих изысканиях я вешал на D+ и D- входы USB - сниффера на FPGA. И это не мешало шине отлично работать. Посему я вам и посоветовал быть смелее ...

Сообщение отредактировал kovigor - Feb 7 2011, 20:02

[andrvisht]

По той, что я предложил, с просыпанием по первому же SOF, пришедшему по принудительно заведенной на GPIO линии D+ (D-) ?

А я эту схему в LPC214x не использовал. Я ее предложил специально вам. На LPC214x все реализуется штатными средствами МК. Я может не так выразился, но в своих изысканиях я вешал на D+ и D- входы USB - сниффера на FPGA. И это не мешало шине отлично работать. Посему я вам и посоветовал быть смелее ...

Ну я примерно так и понял.
Проверял без буфера, просто ногу паралельно на вход прерывания EINT, все работало.
Потом выяснил, что есть возможность просыпаться по той же ноге, но изнутри, и на этом варианте остановился.

Так что решение найдено, спасибо за наставления и помощь.

PS: USB_NEED_CLK так и не удалось сбросить, проблема видать в том, что USBClkSt = 0x13, т.е. младший бит который Reserved по каким-то внутренним причинам = 1. А сам USB_NEED_CLK видать реализован как лог сложение всех битов USBClkSt.
Попытка усыпить контроллер с просыпанием по USB WAKEUP тут же приводит к просыпанию, так как этот бит = 1;