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

[stas00n]

Понадобилось тут "усыпить" STM32F030R8 чтобы только часы работали от резервной батарейки. Сделал вроде все по уму - висячие и не нужные ноги сконфигурировал выходами, где надо pullup/pulldown в нужную сторону, усыпляю - жрет 500 мкА. Перешерстил схему, код, прощупал все в поисках неправильных подтяжек и паразитных питаний - все ОК. Перечитал Reference manual, Datasheet и еррату. Все по науке, криминала не нашел. Поменял контроллер - предположил что подпаленный - результат тот же, - 450-500 мкА.
Вернулся к коду. В начале main инициализирую RCC и GPIO, усыпляю - потребляет 30 мкА, как и должно. Значит проблема в какой-то периферии далее. Копаю дальше не маленький код, тыкаю осциллографом, листаю регистры в отладчике, построчно комментирую. Проблема то появится то исчезнет, на ее локализацию ушло полдня и много нервных клеток.
Причина: используется у меня ножка GPIOB1 как вход для внешнего прерывания в режиме когда подключено основное питание. Подтянута вверх. Во сне эта ножка не нужна и я ее подтягиваю к земле, чтобы не давала паразитного питания на остальную схему которая обесточена. Перед этим, естественно, запрещаю соответствующее прерывание. Причем запрещал только в NVIC, а в регистрах EXTI->IMR, EXTI->FTSR оставлял разрешенным. В результате, как только я (перед сном )дрыгаю этой ногой вниз, взводится флаг в 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();
// Тут отладчик отвалится, смотрим на амперметр.
// Также надо отключить разъем отладчика - он тоже потребляет ток.
}

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

[amiller]

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

[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. Я попробовал и то, и другое (совместно). Никаких изменений в какую-либо сторону потребления.