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

[kovigor]

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

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

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

[andrvisht]

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

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

[kovigor]

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

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

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

[andrvisht]

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

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

[kovigor]

Может не там искал, или не так понял...

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

http://zalil.ru/30373924

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

P.P.S.

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

http://zalil.ru/30376114

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

[andrvisht]

Там надо воздействовать как минимум на регистр PCON. Вот обработчик прерывания, извлеченный из одного из моих проектов для LPC214x.

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

Код

    
FIO2DIR = (1<<3);
if (!(FIO2PIN & (1<<2))) // кнопка для отладки
{
    *((int*)0xFFE0C008) = 1;                           // без этого USB_NEED_CLK всегда 1
    if (FIO2PIN & (1<<3)) FIO2CLR = (1<<3);  else FIO2SET |= (1<<3);  // проверка входа в режим
    USBClkCtrl &= ~0x12;                        // без этого USB_NEED_CLK всегда 1
    while ((USBClkSt & 0x12) != 0x00);
    while (USB_INT_STAT & 0x00000100);
    INTWAKE = 0x20;
    PCON = 0x06;
    USBClkCtrl = 0x12;                        /* Dev clock, AHB clock enable  */
    while ((USBClkSt & 0x12) != 0x12);
    INTWAKE = 0x00;

}

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

Код

if (FIO2PIN & (1<<3)) FIO2CLR = (1<<3);  else FIO2SET |= (1<<3);

срабатывает только при отладке JTAG

Код

PCON = 0x06;

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

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