Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

Форум разработчиков электроники ELECTRONIX.ru _ ARM _ Грабли с энергосбережением STM32F0

Автор: stas00n Jan 25 2018, 09:44

Понадобилось тут "усыпить" STM32F030R8 чтобы только часы работали от резервной батарейки. Сделал вроде все по уму - висячие и не нужные ноги сконфигурировал выходами, где надо pullup/pulldown в нужную сторону, усыпляю - жрет 500 мкА. Перешерстил схему, код, прощупал все в поисках неправильных подтяжек и паразитных питаний - все ОК. Перечитал Reference manual, Datasheet и еррату. Все по науке, криминала не нашел. Поменял контроллер - предположил что подпаленный - результат тот же, - 450-500 мкА.
Вернулся к коду. В начале main инициализирую RCC и GPIO, усыпляю - потребляет 30 мкА, как и должно. Значит проблема в какой-то периферии далее. Копаю дальше не маленький код, тыкаю осциллографом, листаю регистры в отладчике, построчно комментирую. Проблема то появится то исчезнет, на ее локализацию ушло полдня и много нервных клеток.
Причина: используется у меня ножка GPIOB1 как вход для внешнего прерывания в режиме когда подключено основное питание. Подтянута вверх. Во сне эта ножка не нужна и я ее подтягиваю к земле, чтобы не давала паразитного питания на остальную схему которая обесточена. Перед этим, естественно, запрещаю соответствующее прерывание. Причем запрещал только в NVIC, а в регистрах EXTI->IMR, EXTI->FTSR оставлял разрешенным. В результате, как только я (перед сном sm.gif )дрыгаю этой ногой вниз, взводится флаг в EXTI->PR, но прерывание не возникает, поскольку запрещено в NVIC. Так вот, если контроллер теперь положить в любой из энергосберегающих режимов, с установленными битами в PR - он будет потреблять лишние 450 мкА!
Решение:
1. Если надо запретить внеш. прерывание, делать это сначала в периф. модуле, а уж потом, если есть необходимость - в NVIC.
2. После запрета в NVIC - вручную сбросить pending bits, если таковые появились.
3. После выполнения п.2 сразу переводить МК в low power mode, не дрыгая ногами.
Код для "воспроизведения" граблей:

CODE
void Exti_Leak_Test()
{
// Включаем тактирование..
RCC_AHBPeriphClockCmd((RCC_AHBPeriph_GPIOA |
RCC_AHBPeriph_GPIOB |
RCC_AHBPeriph_GPIOC |
RCC_AHBPeriph_GPIOD |
RCC_AHBPeriph_GPIOF ), ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);

// ..и инициализируем GPIO
GPIO_InitTypeDef io;
// Все "не нужные" входы подтягиваем:
io.GPIO_Mode = GPIO_Mode_IN;
io.GPIO_OType = GPIO_OType_PP;
io.GPIO_PuPd = GPIO_PuPd_DOWN;
io.GPIO_Speed = GPIO_Speed_Level_1;
// Пины SWD не трогаем
io.GPIO_Pin = (GPIO_Pin_All & (~GPIO_Pin_13) & (~GPIO_Pin_14));
GPIO_Init(GPIOA, &io);

io.GPIO_Pin = GPIO_Pin_All;
GPIO_Init(GPIOB, &io);
GPIO_Init(GPIOC, &io);
GPIO_Init(GPIOD, &io);
GPIO_Init(GPIOF, &io);

// Настраиваем внешнее прерывание:
SYSCFG_EXTILineConfig(EXTI_PortSourceGPIOB, EXTI_PinSource1);

EXTI_InitTypeDef exti;
exti.EXTI_Line = EXTI_Line1;
exti.EXTI_Trigger = EXTI_Trigger_Rising;
exti.EXTI_Mode = EXTI_Mode_Interrupt;
// ..и разрешаем его в периф. модуле, но не разрешаем в NVIC
exti.EXTI_LineCmd = ENABLE;
EXTI_Init(&exti);

// "Генерируем" прерывание дергая подтяжку на PB1
GPIOB->PUPDR &= ~(0xC);
GPIOB->PUPDR |= 4;

// Ждем нарастания фронта
volatile uint32_t delay = 1000;
while(--delay);

// Возвращаем подтяжку PB1 к земле
GPIOB->PUPDR &= ~(0xC);
GPIOB->PUPDR |= 8;

// Если не сбросить бит в EXTI->PR, будет лишнее потребление тока
//EXTI->PR = 2;

// Переходим в режим STOP
//PWR_EnterSTOPMode(PWR_Regulator_LowPower, PWR_STOPEntry_WFI);
// ..или StandBy
PWR_EnterSTANDBYMode();
// Тут отладчик отвалится, смотрим на амперметр.
// Также надо отключить разъем отладчика - он тоже потребляет ток.
}


Может кому поможет. Сам я не нашел ни предупреждений в документации, ни прецедентов в гугле.


Автор: KnightIgor Jan 25 2018, 11:13

Цитата(stas00n @ Jan 25 2018, 10:44) *
усыпляю - потребляет 30 мкА, как и должно.

Порядком не ошиблись? Чего-то много...

Автор: stas00n Jan 25 2018, 11:45

Цитата(KnightIgor @ Jan 25 2018, 13:13) *
Порядком не ошиблись? Чего-то много...

При измерении не ошибся - 33 мкА. А по даташиту действительно обещается около 3.5 мкА. Видать что-то еще поджирает, будем искать...

Автор: KnightIgor Jan 25 2018, 12:05

Цитата(stas00n @ Jan 25 2018, 12:45) *
При измерении не ошибся - 33 мкА. А по даташиту действительно обещается около 3.5 мкА. Видать что-то еще поджирает, будем искать...

Вы там ноги вниз тянете перед сном. Может где pull-up включен, вот он и жрёт?

Автор: stas00n Jan 25 2018, 12:40

Действительно, забыл подать клок на секцию PWR. Поэтому был режим не standby, а Sleep. Сейчас 3.1 мкА. Спасибо.

Цитата(KnightIgor @ Jan 25 2018, 14:05) *
Вы там ноги вниз тянете перед сном. Может где pull-up включен, вот он и жрёт?

не, уже разобрался - см. выше. пулапы проверены были в первую очередь. Да и в standby режиме все подтяжки отключаются автоматом.. Я еще думал почему у меня порты сохраняют состояние, хотя в ДШ написано обратное.

И, кстати, не сброшенный флаг в EXTI->PR "жрет", получается, только в Sleep mode, а в Stop и Standby - не влияет.

Автор: KnightIgor Apr 27 2018, 16:16

Цитата(stas00n @ Jan 25 2018, 13:40) *
Действительно, забыл подать клок на секцию PWR. Поэтому был режим не standby, а Sleep. Сейчас 3.1 мкА. Спасибо.

Вернулся к теме, т.к. теперь сам тут вожусь с F051, загоняю его в STOP режим и получаю...

Вот тут уже интересно.
У меня два экземпляра платы, совершенно идентичные, однако одна жрет в STOP (если исключить другие чипы, которые в сумме едят 26мкА) где-то 125мкА, а другая 370мкА! Причем та самая внешняя периферия на обеих платах ест одинаково 26мкА, что я определил, усадив F051 экспериментально в полный Standby.

- Тактирование PWR модуля включено.

- Перед входом в STOP:
+ PWR->CR |= PWR_CR_LPDS;
+ SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
+ USART выключается на всякий.
+ ADC выключается, а также запрещаются VREF и TEMP.
+ DAC не используется (он там есть вообще?).

Кто хавает ток в темноте, не знаю...

По ходу обнаружил интересную вещь: у меня используется только внутренний генератор, внешние ножки OSC не используются. Так вот, потребление процессора уменьшается ощутимо, если посадить вход OSC на землю. Правда, я еще не достиг таким образом желаемых 4мкА, но всем может быть полезно: заземляйте вход OSC, если не используется!

Автор: Сергей Борщ Apr 27 2018, 20:19

QUOTE (KnightIgor @ Apr 27 2018, 19:16) *
Кто хавает
Фу. Не в подворотне же.

Из техописания на F030, раздел "I/O system current consumption"
QUOTE
Caution: Any floating input pin can also settle to an intermediate voltage level or switch inadvertently,
as a result of external electromagnetic noise. To avoid current consumption related to
floating pins, they must either be configured in analog mode, or forced internally to a definite
digital value. This can be done either by using pull-up/down resistors or by configuring the
pins in output mode.
Не забывайте, что у кристалла есть выводы, которые не выведены на ноги корпуса.

QUOTE (KnightIgor @ Apr 27 2018, 19:16) *
По ходу обнаружил интересную вещь: у меня используется только внутренний генератор, внешние ножки OSC не используются. Так вот, потребление процессора уменьшается ощутимо, если посадить вход OSC на землю. Правда, я еще не достиг таким образом желаемых 4мкА, но всем может быть полезно: заземляйте вход OSC, если не используется!

Из руководства пользователя F030, F070:
QUOTE
The PC13/PC14/PC15 GPIO functionality is lost when the core supply domain is powered
off (when the device enters Standby mode). In this case, if their GPIO configuration is not
bypassed by the RTC configuration, these pins are set in an analog input mode.
For details about I/O control by the RTC, refer to Section21.4: RTC functional description
on page485
А уже по ссылке написано, что в RTC есть специальные биты для задания режима этих ног в Standby.

Автор: KnightIgor Apr 29 2018, 20:07

Цитата(Сергей Борщ @ Apr 27 2018, 21:19) *
Фу. Не в подворотне же.

После дня борьбы с этими двумя платами с такими разными токами в STOP и безрезультатными попытками посадить процессоры на диету я просто явно себе представил, как эти два процессора, словно две гиены в темноте саванны, издеваются надо мной, совершенно внаглую обгладывают шину питания, срывая с нее электроны, утробно урча и злобно озираясь при этом. Мне удалось выразить мои ощучения одним словом. В любом случае, это лучше, чем "мочить в сортире" из Питерских подворотень.

Касаемо замечания по RTC: моя цель - не standby, а STOP процессора F051K8 (LQFP32). RTC не используется вообще, PC13..PC15 в моем корпусе отсутствуют, но если PC13..PC15 уходят в analog input, то по цитате, "they must either be configured in analog mode" - это просто то, что нужно! Идея с имеющимися, но невыведенными ногами портов, весьма интересна. Попробую, хотя странно это.

Предупреждая идеи, касаемые отдельного генератора для ADC: я его намеренно не использую, тактируя ADC в итоге от HSI, хотя генератор ADC тоже должен стоять в STOP.
В итоге - пока не нащупал, где утекает.



Автор: aaarrr Apr 29 2018, 20:25

Цитата(KnightIgor @ Apr 29 2018, 23:07) *
Предупреждая идеи, касаемые отдельного генератора для ADC: я его намеренно не использую, тактируя ADC в итоге от HSI, хотя генератор ADC тоже должен стоять в STOP.

Хм. На F070 тактирование ADC от HSI приводит к лютому потреблению в STOP.

Автор: KnightIgor Apr 29 2018, 22:33

Цитата(aaarrr @ Apr 29 2018, 21:25) *
Хм. На F070 тактирование ADC от HSI приводит к лютому потреблению в STOP.

Интересно... Надо попробовать. Вроде же все генераторы стоят в STOP. Да и запрещаю я ADC (выключаю ENABLE бит) перед STOP. Пока этого не делал, ADC кушал почти 1mA, о чем, однако, предупреждают в DS или RM (точно уже не помню, где именно).

Автор: aaarrr Apr 29 2018, 22:55

Цитата(KnightIgor @ Apr 30 2018, 01:33) *
Интересно... Надо попробовать. Вроде же все генераторы стоят в STOP. Да и запрещаю я ADC (выключаю ENABLE бит) перед STOP.

Проверьте. Причину такого поведения не искал, т.к. тактирование АЦП от HSI использовал исключительно в порядке эксперимента.

Автор: KnightIgor Apr 30 2018, 15:48

Цитата(aaarrr @ Apr 29 2018, 23:55) *
Проверьте. Причину такого поведения не искал, т.к. тактирование АЦП от HSI использовал исключительно в порядке эксперимента.

Проверил.
- Ничего не меняется в STOP, тактируй я ADC от HSI (PLL/4) или своего родного HSI14. Было ожидаемо: оба HSI в STOP стоят согласно докам. Главное вырубить сам ADC, который ест 0.9mA всегда.
- Ноги OSC - это PF0 и PF1. Перевел их в OUT и определил 0 на выходы. Ну да, теперь можно не заземлять OSC_IN. Этот вопрос решен. Спасибо, Сергей Борщ.
- Пробовал ту же тему с PC13..PC15, которые на моем F051K8 просто отсутствуют. Никаких изменений в какую либо сторону.
- Вроде нашел причину, почему две платы кушали разные токи в STOP. В схеме есть SN65HVD72. Когда укладывал систему спать, я выключал UART2, хотя, наверное, можно этого и не делать. При этом на TX почему-то появлялся потенциал ощутимо меньший логической "1" (в районе 2V вместо 3.3V). Предположительно, этот промежуточный потенциал переводил вход SN65HVD72 в состояние линейного усилителя, потребление которого разнится от экземпляра к экземпляру. Теперь я перед сном "забираю" линию TX у UART2 и программирую её как обычный GPIO c выходом логической "1". Понятное дело, -RE и DE чипа SN65HVD72 управляются от отдельных GPIO, которые устанавливаются в запреты перед сном. Разброс потребления между экземплярами ушел, оба потребляют 125мкА, 25мкА из которых съедает внешняя периферия: SN65HVD72, FM24LC04B, BQ24232, MCP1702 и некий Pull-up в 1M, если в подробности не вдаваться.

Короче, 100мкА куда-то текут. Цель - 4мкА из дока - пока не достигнута.

Автор: amiller May 1 2018, 05:16

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

Автор: k155la3 May 1 2018, 10:23

Цитата(amiller @ May 1 2018, 08:16) *
. . . . А периферию, ненужную во время сна, нужно было питать от другого (отключаемого) источника. . . .
На макетных испытаниях (платформа MSP430+CPLD) по такой схеме потребление не только не понизилось, а наоборот, возросло и "плавало".
(возможно - из-за образования "неопределенных" уровней на входах контроллера). Пробовали подтягивать входы вверх-вниз - ерунда получалась.
Кроме отключения АЦП надо проверять неактивность REF. Возможно вход АЦП перевести в режим цифрового входа.
Если остался неподключенный цифровой вход, или цифровой вход, на который приходит импульсный-частотный сигнал - ОНО будет потреблять
динамический ток переключения цепей входной периферии. Ток потребления (всей схемы) смотреть с низкоомного шунта, подключенного к земле.
Или использовать изм. усилитель (тогда можно шунт ставить "вверху" и смотреть по узлам схемы).

Автор: amiller May 1 2018, 11:44

Цитата(k155la3 @ May 1 2018, 13:23) *
На макетных испытаниях (платформа MSP430+CPLD) по такой схеме потребление не только не понизилось, а наоборот, возросло и "плавало".

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

Автор: k155la3 May 1 2018, 11:51

Цитата(amiller @ May 1 2018, 14:44) *
Может я некорректно выразился, но здесь я имел в виду не ту периферию, что входит в состав МК, а внешние микросхемы, которые питаются от одного с МК источника (как я понял ТС).
Не, все правильно. У нас отключалась внешняя периферия - CPLD


Автор: KnightIgor May 3 2018, 10:37

Цитата(amiller @ May 1 2018, 06:16) *
А ток потребления измеряете до линейника 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 May 4 2018, 12:41

Цитата(KnightIgor @ May 3 2018, 11:37) *
Как я писал в этой ветке чуть выше, я имею потребление в 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 May 4 2018, 13:54

Цитата(KnightIgor @ May 3 2018, 13:37) *
Как я писал в этой ветке чуть выше, я имею потребление в 25мкА, если перевожу процессор в режим STANDBY, при котором он не ест почти ничего. То есть, 100мкА из 125мкА моего режима STOP съедает явно процессор.

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

Автор: KnightIgor May 7 2018, 18:40

Цитата(Baser @ May 4 2018, 14:54) *
Это еще не факт, ибо в Standby почти все порты аппаратно переключаются на вход без подтяжек, а при STOP они сохраняют свое состояние. Поэтому проверьте все уровни на ножках.
Еще может быть эффект с уровнем в половину питания на плавающей ножке. Столкнулся с этим на STM32L1 в Standby:

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

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

Автор: zhevak May 14 2018, 07:35

Цитата(KnightIgor @ May 7 2018, 23:40) *
Где копать дальше - не знаю.


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 May 15 2018, 07:35

Цитата(zhevak @ May 14 2018, 08:35) *
1. Не отчаиваться!

biggrin.gif

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

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

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

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

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

Не забываю sm.gif.

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

Может MSP432?

Автор: zhevak May 15 2018, 07:50

Цитата(KnightIgor @ May 15 2018, 12:35) *
Может MSP432?


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

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

Добавлено.
А вот хрен там! -- Не удержался, дописал-таки строку перевода внутреннего регулятора в режим энергосбережения.
Код
    PWR->CR |= PWR_CR_LPDS;              // Регулятор (1.8 В) в энергосберегающий режим

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

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

Автор: zhevak May 20 2018, 06:09

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

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

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

Код
  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.


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

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

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

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

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

Автор: KnightIgor Sep 26 2018, 12:36

Цитата(Сергей Борщ @ Apr 27 2018, 21:19) *
Из техописания на 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.


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

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)