Грабли с энергосбережением STM32F0, STM32F0 low power mode, exti Опции

[k155la3]

Может я некорректно выразился, но здесь я имел в виду не ту периферию, что входит в состав МК, а внешние микросхемы, которые питаются от одного с МК источника (как я понял ТС).

Не, все правильно. У нас отключалась внешняя периферия - CPLD

[KnightIgor]

А ток потребления измеряете до линейника 3V3 или после? 100 мкА вполне может оказаться собственным потреблением LDO, если он выбран неправильно.
А периферию, ненужную во время сна, нужно было питать от другого (отключаемого) источника. Иначе возникает сомнение, где тут ток периферии, а где ток контроллера, теоретические умозаключения?
При соблюдении этих условий на F1 и F4 удавалось добиваться потребления в соответствии с документацией без танцев с бубном.

В качестве LDO выбран MCP1702, который имеет Iq = 2мкА и который, в свою очередь и согласно графикам дока, растет незначительно до тех токов (~0.13mA), которые сейчас имеют место в режиме STOP. На входе LDO (в режиме STOP процессора, когда он обнаруживает пропадание 5V внешнего питания) - примерно 4V от LiPo акумулятора. Ток я меряю как раз из аккумулятора. Зарядом акку и переключением нагрузки при пропадании питания 5V занимается BQ24232 (то есть, выход BQ24232 подан на вход LDO).
Как я писал в этой ветке чуть выше, я имею потребление в 25мкА, если перевожу процессор в режим STANDBY, при котором он не ест почти ничего. То есть, 100мкА из 125мкА моего режима STOP съедает явно процессор.

[KnightIgor]

Как я писал в этой ветке чуть выше, я имею потребление в 25мкА, если перевожу процессор в режим STANDBY, при котором он не ест почти ничего. То есть, 100мкА из 125мкА моего режима STOP съедает явно процессор.

Еще одним подтверждением процессора как источника "лишнего" потребления служит обнаруженный мной только что эффект роста потребления при нагревании процессора: даже приложив просто палец к корпусу процессора (то есть, нагрев на примерно 10 градусов), я наблюдаю немедленный рост потребления на примерно 12мкА. Оно же падает постепенно, если палец убрать. Иные компоненты как FRAM, RS485 чип и LDO на плате никак не "реагируют" в смысле потребления на ласковое прикосновение.

Перечитал ERRATA на чип.
Есть несколько упоминаний режима STOP.

В частности, есть и правда упоминание о PC0..PC5, которые не выведены на ножки малых корпусов, но присутствуют. Написано, что эти линии портов устанавливаются аппаратно в "безопасное с точки зрения потребления" состояние, и не рекомендуется перепрограммировать их в состояние аналогового входа, особенно, если VDDA больше VDDIO, что приводит к увеличению потребления на десяток мкА по каждой линии. Я их и не трогаю, да и VDDA у меня - те же 3.3V питания, разве что через ferrit bead.

Перед переходом в STOP надо также убедиться о завершении транзакций по I2C. Рекомендуют для верности деактивировать I2C. Я попробовал и то, и другое (совместно). Никаких изменений в какую-либо сторону потребления.

[Baser]

Как я писал в этой ветке чуть выше, я имею потребление в 25мкА, если перевожу процессор в режим STANDBY, при котором он не ест почти ничего. То есть, 100мкА из 125мкА моего режима STOP съедает явно процессор.

Это еще не факт, ибо в Standby почти все порты аппаратно переключаются на вход без подтяжек, а при STOP они сохраняют свое состояние. Поэтому проверьте все уровни на ножках.
Еще может быть эффект с уровнем в половину питания на плавающей ножке. Столкнулся с этим на STM32L1 в Standby:
Поднимаю напряжение (независимое) на отключенной ноге WakeUp - начинает расти потребление от батареи!
Сначала микроамперы, а при половине питания до 80 мкА лишних потекло. А вроде бы какая связь, источники то разные

[KnightIgor]

Это еще не факт, ибо в Standby почти все порты аппаратно переключаются на вход без подтяжек, а при STOP они сохраняют свое состояние. Поэтому проверьте все уровни на ножках.
Еще может быть эффект с уровнем в половину питания на плавающей ножке. Столкнулся с этим на STM32L1 в Standby:

Да, я проверял все уровни, благо, ножек не много. Так я обнаружил "средний" уровень на TX процессора, когда я деактивировал его UART, что приводило в итоге к значительному росту потребления (скорее) со стороны RS485 чипа. Я перестал деактивировать UART, т.к. этот узел ничего не потребляет в STOP, однако сохраняет управление TX и уровень последнего. Все это немедленно улучшило ситуацию. Остальные ноги находятся на определенных предусмотренных уровнях, не "тягаясь" с кем-то снаружи. Если предусмотрены Pull-up, так и внешние OK транзисторы закрыты, и т.п. Единственный аналоговый вход имеет действительно примерно половинное питание от выхода операционника. Этот вход определен как аналоговый, а не цифровой вход, а операционник - вообще TLV2401, который "кушает" 0.9мкА.

Где копать дальше - не знаю.

[zhevak]

Где копать дальше - не знаю.

1. Не отчаиваться!

2. Возможно я не прав, но я бы сначала сдул с платы всю (потребляющую или возможно потребляющую)
периферию. Оставил бы МК "голым", в гордом одиночестве. И в такой конфигурации попытался бы
получить нужное потребление. Потом бы шаг за шагом добавлял на плату периферийные микросхемы.

3. Когда я работал с MSP430, то в книжке (по моему вроде в книжке автора Фрузе) приводилась наглядная
диаграмма сквозного тока у полевых структур, который возникает при входном напряжении, близком к
половине питания. К сожалению, эту картинку я не смог найти, но нашел другую:


Зрительные образы лучще запоминаются.

4. И ещё -- выдержка из книжки John H. Davies "MSP430 Microcontroller Basics" (она в инете выложена в pdf)

[page 215]
7.2.1 Configuration of Unused Pins

Not all of the input/output pins are used in most applications. Unused pins must never be
left unconnected in their default state as inputs. This follows a general rule that inputs to
CMOS must never be left unconnected or ”floating.” A surprising number of problems can
be caused by floating inputs. The most trivial is that the input circuit draws an excessive
current from the power supply. This is because the input is likely to float to the midpoint
of V SS and V CC , turning on both MOSFETs and leading to the situation shown in
Figure 7.2©. The shoot-through current may exceed 40 ␮A, a huge waste by the standards
of the MSP430.

Old CMOS circuits, such as the 74HC family, are amazingly sensitive to floating
inputs. They may oscillate or refuse to work at all if an input is floating, even if the input
belongs to an unused gate or flip-flop. I have seen this happen many times when students
have not taken heed of the rule about floating inputs. Missing decoupling (bypass)
capacitors can cause similar problems. Floating inputs are also susceptible to noise
and to static electricity if the product is handled, which may lead to permanent
damage.

There are three ways of avoiding these problems:

1. Wire the unused pins externally to a well-defined voltage, either V SS or V CC , and
configure them as inputs. The danger with this is that you might damage the MCU
if the pins are accidentally configured as outputs.

2. Leave the pins unconnected externally but connect them internally to either V SS or
V CC by using the pull-down or pull-up resistors. They are again configured as
inputs. I prefer this approach but it is restricted to the MSP430F2xx family
because the others lack internal pull resistors.

3. Leave the pins unconnected and configure them as outputs. The value in the
output register does not matter. This is perhaps the most robust solution and is
recommended for MSP430 devices that lack internal pull resistors. I am less keen
on this approach for experimental systems because it is easy to short-circuit pins
with a test probe.

There is a helpful list of recommended connections for unused pins at the end of the
chapter on System Resets, Interrupts, and Operating Modes in the family user’s
guides.

In some manufacturers’ devices the unconnected bits of a port may be present on the chip
itself but are not bonded to pins. In this case it is important to configure all bits of the port
correctly, including those that are not connected to the outside world. This issue arises
when the same integrated circuit (the same ”silicon”) may be offered in packages with
different numbers of pins. I believe that this does not apply to the MSP430. However, a
few input/output registers contain bits without corresponding pins. For example, the
F1121A has all 8 bits of P2IFG implemented on silicon but there are pins for only
P2.0–P2.5. The bits for the missing pins 6 and 7 can be used for software interrupts.

Собственно, об этом С.Борщ сказал уже.

5. А Вы, случаем, не забываете отключить от платы программатор, когда измеряете потребление?
У меня при подключении st-link (по SWD) потребление сразу возрастает.

6. Мне тоже нужно загнать свой девайс в спячку. Проц MSP430F030C8. Питание проца 3.3 В.
Режим "спчки" -- STOP. Внутренний стабилизатор LDO на 1.8 В, я НЕ перевожу в
малопотребляющий режим. Все биты портов проинициализированы и развёрнуты на выход.
В том числе биты, которые предназначены для подключения кварцевых резонаторов. Вся
внутренняя периферия (за исключенимем PWR и RTC) отключена. Главный цикл программы
пустой:

Код

  while (true)
  {
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
    __WFE();
  }

Просыпаюсь раз в секунду (от Alarm), зажигаю сетодиод на 5 мкс и тут же гашу -- потребление
33 мкА, Если просыпаюсь 128 раз в секунду (тоже по событию от AlarmA), то потребление
возрастает до 40 мкА.

Следует заметить, что разные тестеры (типа традиционного 838-го) показывают разное
потребление. Показания колеблются от 27 мкА до 40 мкА.

[KnightIgor]

1. Не отчаиваться!

2. Возможно я не прав, но я бы сначала сдул с платы всю (потребляющую или возможно потребляющую)
периферию. Оставил бы МК "голым", в гордом одиночестве. И в такой конфигурации попытался бы
получить нужное потребление. Потом бы шаг за шагом добавлял на плату периферийные микросхемы.

Запланировано.

4. И ещё -- выдержка из книжки John H. Davies "MSP430 Microcontroller Basics" (она в инете выложена в pdf)

Все входы-выходы перепроверил, никаких неопределенностей нет, все, что не задействовано (пара ног), - определено.

5. А Вы, случаем, не забываете отключить от платы программатор, когда измеряете потребление?

Не забываю .

6. Мне тоже нужно загнать свой девайс в спячку. Проц MSP430F030C8.

Может MSP432?

[zhevak]

Может MSP432?

Ой! Это описка. Я сейчас работаю с STM32F030.

Сегодня, если сподоблюсь попробую внутренний стабилизатор (1.8 В) переводить в экономичный режим.
По результатам отпишусь здесь же.

Добавлено.
А вот хрен там! -- Не удержался, дописал-таки строку перевода внутреннего регулятора в режим энергосбережения.

Код

    PWR->CR |= PWR_CR_LPDS;              // Регулятор (1.8 В) в энергосберегающий режим

В результате получил снижени потребляемого тока ещё на 10 мкА (как и описано в ДШ).

Перед зпливкой проги тестер показывал 31-32 мкА (вчера почему-то показывл 27 мкА, наверно проц
был холодный, только принёс с улицы). После заливки показывает 19-20 мкА.

[zhevak]

Коллеги! Двумя комментариями выше я привёл код, который отправляет МК в спячку.

В коде ошибка!

Правильный код должен быть таким:

Код

  while (true)
  {
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;   // Задаём режим STOP
    PWR->CR |= PWR_CR_LPDS;              // Регулятор (1.8 В) в энергосберегающий режим
    __WFI();                             // Спать!!!
  }

Вместо команды __WFI() я написал __WFE(). Написал и даже как-то не обратил на это внимание. Видимо, был сосредоточен на чём-то другом. Хуже того -- код с опиской (ошибкой) благополучно заработал.

На присутствие в коде ошибки я обратил внимание только тогда, когда моё устройство стало вести себя мягко говоря странно. Моё устройство -- это телефонная трубка. При пятисекундном нажатии на клавишу "повесть трубу" (красная кнопка) устройство должно было засыпать или наоборот -- просыпаться. На деле устройство меняло режим работы не через 5 секунд, а через 2-3.

Хорошо! Я увеличил порог до 10 секунд. Теперь устройство стало издевательски засыпать и просыпаться через 5 секунд.

"Стрелка осциллографа" показала, что устройство засыпало не стразу, а только когда главный цикл (в main()) совершит ещё один оборот и команда __WFE будет выполнена повторно.

Всё правильно! Команда WFI переводит МК в спячку не взирая на. А вот команда WFE работает немного по другому.

Если флаг однобитового регистра события сброшен, то команда отработает как и положено -- отправит МК в спячку. Но если этот бит взведён, то команда WFE не сможет усыпить МК. Вместо этого она просто сбросит этот бит. Поэтому повторное выполнение команды WFE уже будет происходить со сброшенным флагом, поэтому только оно (то есть, повторная команда) и загонит МК в сон.

Programming manual PM0215 так об этом и говорит (страница 29, в средине):

Wait for event

The wait for event instruction, WFE, causes entry to sleep mode depending on the value of
a one-bit event register. When the processor executes a WFE instruction, it checks the value
of the event register:

● 0: the processor stops executing instructions and enters sleep mode
● 1: the processor clears the register to 0 and continues executing instructions without
entering sleep mode.

If the event register is 1, this indicates that the processor must not enter sleep mode on
execution of a WFE instruction. Typically, this is because an external event signal is
asserted, or a processor in the system has executed an SEV instruction, see SEV on
page 66. Software cannot access this register directly.

Для таких как я это положение повторено в руководстве дважы.

К стати, обратите внимание на последнее предложение -- однобитный регистр события программно не доступен.

Ну, и что в итоге? После разумного подхода всё встало на свои места -- трубка засыпает и просыпается после 5-секундного нажатия, и энергопотребление в режиме STOP снизилось еще примерно на 10 мкА и составило примерно 9 мкА.

Такие токи достаточно сложно измерять традиционными (китайскими) тестерами типа 828-го. На работе тестер показывает 9 мкА, мой домашний -- 14 мкА.

Буду польщён, если этот камент кому-то поможет избежать проблем.

[KnightIgor]

Из техописания на F030, раздел "I/O system current consumption"Не забывайте, что у кристалла есть выводы, которые не выведены на ноги корпуса.

Таки да!
Я тему возобновляю коротко, чтобы сообщить, что я нашел причину повышенного потребления: это и вправду неиспользованные и НЕВЫВЕДЕННЫЕ ноги, но только не PC13..PC15 и иже с ними, или PF0 и PF1, а... PB2 и PB8.
Дело в том, что всяких PC13..PC15 или PC0..PC5 (то есть, порта C) в процессоре STM32F051K8T в LQFP32, похоже, действительно нет, т.к. манипуляции с ними ни к чему не приводили. А вот PB2 и PB8 - есть! Дело в том, что STM32F051K8U в QFPN32 имеют эти выводы снаружи, на LQFP32 - нет снаружи, но явно есть внутри! В DataSheet на странице 36 в сноске 4 меленько написано:

On the LQFP32 package, PB2 and PB8 must be set to defined levels by software, as their corresponding pads on the
silicon die are left unconnected. Apply the same recommendations as for unconnected pins.

Как только я установил эти ноги как выходы с низким уровнем, потребление упало до заявленного!
Еще раз спасибо за наводку по ногам. Пришлось долго искать, какие это именно.