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

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


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

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

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

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

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

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

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

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

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

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