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