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;

[kovigor]

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

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

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

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

[andrvisht]

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

у них там так и написано.
USB_NEED_CLK is asserted if any of the bits of the USBClkSt register are asserted.
а вот что имелось ввиду под словом любой, остается тайной.
Техподдержка не отвечает. Запрос отправлял через офф. сайт, а там конкретных email нету, и мучать некого ... а я бы помучал

Сегодня пришло письмо, с просьбой подождать еще 5 дней.
Тем временем я выяснил, что USB_NEED_CLK все таки сбрасывается, но только при работе в железе.
Т.е. если ходить JTAG-ом то в USBClkSt всегда установлен младший бит, и соответственно USB_NEED_CLK всегда 1. А при работе процессора в нормальном режиме, этот бит 0, и все происходит правильно.
Однако это не решает проблемы, так как при установки USBWAKE бита просыпания контроллера не происходит. Может нужно самому выключить PLL так как при Power Down она не выключается, может еще что ... пока не выяснил. Но появился новый вопрос в техподдержку, буду продолжать долбить.