Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: LPC288x power down
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
IgorMarx
Здравствуйте всем.

Делаю проект на LPC2888/01 (корпус BGA 180 с шагом 0.5). Пока было всё "хорошо", но настал момент, когда проц нужно положить спать. Процедура, описанная в юзер мануале, реализована; пины на вывод, внешних нагрузок нет, аналоговые цепи отключены через регистры, осциллятор остановлен, JTAG не подключен и т.п. Камень продолжает потреблять примерно 4 мА, из которых примерно 1,5 через стабилизатор уходит в шину 1.8V. Код, написанный в среде IAR Embedded Workbench, проверен на плате Olimex-H2888 и на плате разрабатываемого устройства, результат одинаковый. Мало того, взят пример из оригинального code bundle от NXP, разработанный для платы Nohau в Keil и доработанный, чтобы уходить в спячку на этих платах, даёт те же результаты.

Перерезание дорожек на плате показало, что ток течёт по шинам питания, кормящим встроенный USB. Мало того, подача разных уровней на аналоговые входы немного влияет на ток потребления в этом режиме.

Интересные факты:
1. В readme на code bundle написано, что данный проект сгенерирован, но НЕ ТЕСТИРОВАЛСЯ (Ого! Это что же помешало, интересно?)
2. В Интернете нигде нет упоминания о том, чтобы какое-либо батарейное устройство было успешно реализовано на этом чипе;
3. Звонок куратору и написание письма в NXP с просьбой предоставить образец реально работающего кода, уводящего камень в спячку пока остались без ответа.

Вопрос в следующем: есть ли кто-либо, имевший дело с процом и добившейся его нормального засыпания?
alexQ
ответил в личку
etoja
Цитата(IgorMarx @ Sep 7 2009, 11:19) *
1. В readme на code bundle написано, что данный проект сгенерирован, но НЕ ТЕСТИРОВАЛСЯ (Ого! Это что же помешало, интересно?)


Процедура тестирования в NXP гораздо серьёзнее, чем предполагают радиолюбители.
И вас об этом честно предупредили.
IgorMarx
Цитата(etoja @ Sep 7 2009, 14:50) *
чем предполагают радиолюбители.


Сумничали? А что скажете по теме?


Извините, если обидел и это не личное, но на этом форуме не придраться просто не могут.
IgorMarx
Разобрался сам.
Код
    SetCoreMode(eMode60MHz);
    USBCLKEN = 1;
    USBLOCK = 0xAA37;
    USBTEST = (1 << 4);
    USBMODE = USBMODE & 0xfe;    //clear SOFTCT
    USBMODE = (USBMODE & 0xfe) | (1<<4); // issue soft reset
    USBMODE = USBMODE & (0xfe & ~(1<<4)); // remove soft reset
    for (volatile unsigned i=0; i<60000000UL / 100; i++);// wait at lest 3 ms (we wait more)
    USBTEST = 0;
    USBLOCK = 0xAA37;
    //Issue soft reset
    USBMODE = (USBMODE & 0xff) | (1<<4); // issue soft reset
    USBMODE = USBMODE & (0xff & ~(1<<4)); // remove soft reset
    // wait for suspend interrupt
    while ((USBINTSTAT & (1<<3)) == 0);

    USBMODE = (USBMODE & 0xfe) | (1<<5); // GOSUSP
    USBCLKEN = 0;

    SetCoreMode(eMode12MHz);


Плюс резистор с D- на землю.

P.S. Тут есть лишнее.
shahr
Цитата(IgorMarx @ Sep 8 2009, 14:13) *
Разобрался сам.


То есть вопрос в NXP support мы закрываем?

Цитата(IgorMarx @ Sep 7 2009, 11:19) *
3. Звонок куратору и написание письма в NXP с просьбой предоставить образец реально работающего кода, уводящего камень в спячку пока остались без ответа.

Ответ из NXP предоставлен.
IgorMarx
shahr, да, спасибо, ответ сегодня получил по почте. То, что написано выше, снижает ток потребления до 600 мкА. Посмотрю, как будет работать присланный тестовый код.

Насчёт закрытия вопроса в NXP support: пока не удалось успешно повторно усыпить процессор после пробуждения (остаётся 8 мА) - с моим кодом. Там много устройств инициализировано.
IgorMarx
Потратил день, стараясь добиться ухода в спячку процессора с присланным кодом. Ничего не получается - те же самые 4 mA. Те же изменения тока потребления при изменении потенциала на входах USB контроллера. Один раз чип всё же ушёл в PD, но тот же код перестал работать при перезапуске. В присланном примере не всё ясно: шина AHB программируется на 60 MHz (понятно для чего - на AHB должно быть не менее 30 MHz, чтобы получить доступ к регистрам контроллера USB), а мосты APB - на 32 kHz. Это не даёт топать отладчиком.

Явно чего-то не хватает, какие-то условия не выполняются.

Достал свой проект, в котором приведённый выше рецепт сработал - уже не срабатывает. Чудеса в решете, впечатление такое, что я не в своём уме: то работает, то нет. Ошибиться сложно, у меня стоит Perforce, я могу после экспериментов всегда откатить код на контрольную точку.

Проверял на нашей многослойке. Завтра проверю на Olimex'е, когда попадёт в руки родная Nohau, посмотрю на ней.

Пока результат отрицательный.
IgorMarx
Дошёл до положительного результата, как мне кажется. Раз уж я тут сам с собой общаюсь, то выложу результат. Наверняка кому-нибудь эта информация станет полезной, дабы не тратить чудовищное количество времени.

Как написано в user manual на микросхему, для перевода микроконтроллера в режим пониженного энергопотребления, среди прочего, нужно выполнить

Код
USBCLKEN = 0;


На практике этого совершенно недостаточно. Оказывается, нужно сделать следующее:

1. Подать на шину AHB частоту не менее 30 MHz
2. Подать программно-аппаратный сброс на устройство USB (оказалось, что иначе после пробуждения при попытке обратиться к регистрам USB ядром последнее подвисает, и отвисает, только если на входных линиях что-то дёрнется).
3. Разрешить клок;
4. Разлочить регистры USB;
5. Подать программный сброс через регистр USBMODE;
6. Дождаться бита статуса suspend;
7. Установить бит GOSUSP в USBMODE;
8. Запретить клок.

Код
    MODE1_7 = 0;
    MODE0_7 = (1<<0);
    SetCoreModeeMode60MHz);
    USBRES = 0;
    USBRES = 1;
    USBCLKEN = 1;
    USBLOCK = 0xAA37;
    USBMODE = 0x10;
    USBMODE = 0;
    while ((USBINTSTAT & (1<<3)) == 0);
    USBMODE = 0x20;
    USBCLKEN = 0;
    SetCoreMode(eMode12MHz);


Вот только тогда USB будет реально отключен. Но и это не всё. Не знаю, насколько корректно вешать подтяжки на аналоговые входы USB, но это позволяет спасти ещё примерно микроампер 200.

Спасибо всем за поддержку.

P.S. Хотелось бы всё же увидеть этот рецепт в юзер мануале на микросхему. Хотя бы в будущих редакциях.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.