STM32F103C8T6 extreme low power consumption (frequency, periphery)

Wed Jun 08, 2016 3:13 pm
Hi I need to make STM32F103C8T6-based device which run on 2x AA battery (3V).
Device will be counting pulses on digital input pin (about 1-10 pulses each minute).
Device will send status each minute over 443MHz radio:

I need *maximum* possible battery life.

STM32F103C8T6 will sleep all time. Pulse input will be on interrupt pin and wake up stm. After that stm go to sleep again.

Arduino ATmega328 has in datasheet:
Power Consumption at 1MHz, 1.8V, 25°C
̶ Active Mode: 0.2mA
̶ Power-down Mode: 0.1µA
̶ Power-save Mode: 0.75µA (Including 32kHz RTC)

Wed Jun 08, 2016 3:23 pm
Please read this post:

In addition, grab the STM32 Reference Manual – use Google to search for it. Read about the power domains in the chip. There are also Application Notes about power savings by chip architecture – again use Google.


Wed Jun 08, 2016 9:30 pm
Like Ray says..

You will need to read the manual for the chip.

You can change the PLL multiplier, to a lower value, but I dont know off the top of my head what the lowest multipler is.

There is also a 2 x prescaler on the clock, so I suspect the minimum frequency would may be 8Mhz / 2, assuming there is a x1 Pll multiplier setting ( you need to check the manual)

But if you change the master clock freq, all the timings in the core will be wrecked.
e.g. UART timings will be wrong, Systick e.g. millis will be wrong, delay() will be wrong etc etc

Wed Jun 08, 2016 11:38 pm
marti159 wrote:
How is it on STM32F103C8T6? Lower frequency = lower power consumption?

How can I decrease frequency? Now I have blue pill with 8.0MHz crystal and ticks at 72MHz. Is possible to set frequency to for example 2 or 8 MHz instead of 72MHz? Can I use 8MHz crystal an reduce frequency in software like fuses on Atmel AVR? Is there any minimal frequency?

Thu Jun 09, 2016 7:27 am
I am not sure but I read that a short fast burst and longer sleep is not better for batteries. It seems that batteries (maybe not all type of batteries) prefer to have a bit longer operations but at a lower mA that a short burst at high mA.

But I never made an experiment nor I read about a similar experiment. Maybe it is only an opinion.

usually boards are not designed for low power operation and you must design your board or you have to modify common boards. The only low power boards that I saw are the TI Launchpad (various models) and some specialised Arduino board.

Thu Jun 09, 2016 8:07 am
I found STM32CubeMX software, that can calculate power consumption with enabled peripheries. Screenshots of stm32cubemx.

If I generate some C code in STM32CubeMX how can I use it in “Arduino STM32”?

At this topis in this forum is Arduino code with STM C:
#include <stdint.h>
#include <libmaple/pwr.h>
#include <libmaple/scb.h>

#define BOARD_LED_PIN 33

// These are possibly defined somewhere but I couldn't find them. System Control Register
#define SCB_SCR_SLEEPDEEP 4 // Controls deepsleep(1) or sleep(0)
#define SCB_SCR_SLEEPONEXIT 2 // Controls sleeponexit (not used here)

volatile bool ledState = LOW; // Used in ISR blinkState()


void loop()
//SerialUSB.println("HI!"); delay(100); // Only works on first iteration, before stop mode

// Clear PDDS and LPDS bits

// set sleepdeep in the system control register

// Now go into stop mode, wake up on interrupt
asm(" wfi");

digitalWrite(BOARD_LED_PIN, ledState);


Thu Jun 09, 2016 11:52 am
zoomx wrote:I am not sure but I read that a short fast burst and longer sleep is not better for batteries. It seems that batteries (maybe not all type of batteries) prefer to have a bit longer operations but at a lower mA that a short burst at high mA.

Fri Jun 10, 2016 9:59 am
There is a lot of good information regarding battery life and microcontrollers, but there is also quite a lot of dross (advertising for the latest fantoosh version of the big boy silicon players latest iteration of their take on low power microcontrollers using their in house magic sauce mainly).

This might whet your appetite, however for most small projects, it is fairly easy to set up your multimeter to watch the current being fed to the board(s) and get a reasonable ball park figure.

Fri Apr 07, 2017 7:28 am
Interesting, insightful, thought/comments, and points for this thread of discussion.

What I am tring to find at moment is what sort of cable, jig or such one uses to measure the current and voltage? I have a sense a jig is what is likely needed. I suspect there are as many different ways to design a jig as are projects.

I am still trying to find out if makes sense to connect a battery to a pin directly or power via the USB. Many have commented the voltage regulators of many MCUs have low insertion related losses. So far the research reading I have done on this seems to have some mixed opinions. This would suggest to me additional tests to find out the current/battery profiles the MCU has in context of the complete solution. Perhaps compare direct vs via the regulator vs the pros/cons of.

I tend to find out the real world results and have the data for. Using the datasheets and prior research/projects as starting point of design. Sometimes there is a refinement/learning process that unfolds to improve design one feels or sees as issues. Sometimes one finds out prior experience gained means one was close or as close as can be. The other sometimes is just a varied combination of many factors.


John L. Males
Toronto, Ontario
07 April 2017 03:28 EDT

Fri Jun 02, 2017 8:29 am
there are also various ‘lipo fuel gauges’ and coulomb counters which might be useful if one is looking out for a ‘battery meter’ … o&_sacat=0 … okup-guide

often running on ‘low power’ isn’t simply about the mcu, the peripherals consume power too, hence, it’d be necessary to try to limit the peripherals power draw, e.g. turn off clocks for peripherals not in use.

then there is that *huge battery consuming* **systick counter*, it would keep the device awake each tick every milliseconds
disable the systick interrupt if it isn’t needed systick_disable();

Fri Jun 02, 2017 11:04 pm

I am likely to run the device on rechargable AA batteries and not a LIPO. Availability is primary factor, and LIPO in colder temperatures is second factor.

For sure not just uC power is part of battery budget calculation. Peripherals for sure, external and built in. Hence my what the real world current draw will be is what I need to know. I asked about the base uC current draw as that is a starting point for choice and what internal functions not using that may reduce current draw before peripherals.

I will be using a DS3231. I assume that will mean the systick counter will not be needed? The design for the personal project I am trying to create has always had a DS3231 in the design from start.

I will not need the USB. I will use an upload method that uses the least flash in terms of overhead. If that means serial download of sketch that will likely be what it will be or maybe STLink.

The primary peripheral has no interrupt. I will likely apply some approach of sleep design in code that uses a timer asuming that does not imply the need for the systick counter to do so.

I may need the 72Mhz later in the greater functionality of the design. I can test the design for the initial base functionality I need to start at 48Mhz to see if that helps in reducting current draw.

I have not decided if and what communications device I will use. The design needs a SD/MicroSD as part of the minimum design. For sure the design only needs the communications device on in what is a user on demand mode. So button or such to toggle on/off when need communications. Expectation is the toggle will be used a couple times a day. How long on I am not sure as depends how long takes to transmit the data. I will not know the transmit time until I prototype one or more communication functionality choices to evaluate. The first stage of functionality will only implement DS3231, SD/MicroSD and one external I2C peripheral that talks to downstream peripherals. The downstream peripherals current draw is about 0.001nA in standby and 1.5mA for a second or less once every several seconds.

Those BLE trackers you mentioned maybe means I would be better using bluetooth communications for data transfer rather than WiFi. Even when a communications device is off it still draws power. The amount of current draw of a idle/off communications device may not be what will make sense for the couple times a day I need the communications device on for. This is similar to the the common suggestion I have a display to display current values. An OLED seems too small and has finite lifespan. A 1602 will be fine for my needs in terms of what would be displayed, but again how much need to look at vs current draw results in my respose to those wanting me to include (Yes it is a one of personal device others may wish to see values the very limited times they wish to.) when I had not even considered doing so in the larger functional design. All I know is a communications device is more important than a display for what I need. If a bluetooth device has low enough current draw when not active doing communications then I will consider. A communication device will be staged above the basic minimum design I have needed for many months. The months delay due mostly to very skewed delivery times big time in order of 120-150 days and odd factor of what I think will be appropriate for what I am trying to acheive that I was wrong about are the delay factors. The former the major reason. When I am incorrect on what I need for a solution I have to figure out what I do to acheive the desired functional goal and then order what I need, ergo adding to the delays.

I was expecting to have a the basic functionality later part of December 2016. I started out my research on if, how, and what I need a year ago. I started my ordering of parts late last summer over to November 2016 where orders as of September 2016 started to take over to well over 60 days. I stopped ordering other parts I would need mostly because I had no idea if what I ordered would arrive. I had no idea orders would take 120-150 days to arrive. That has caused serious delays to what I am trying to make that is important for me and nobody else.

Your points are most helpful.


John L. Males
Toronto, Ontario
02 June 2017 19:04 EDT
02 June 2017 19:42 EDT Typo correction

Sat Jun 03, 2017 5:13 pm
the main trouble with systick is *it keeps the mcu awake*
the systick interrupt mainly updates systick_uptime_millis … tick.c#L84
i think this is used by the functions millis(), micros(), and you may be caught off guard but delay() uses millis()
so if you have codes that dodelay(100) //delay 100ms

Sat Jun 03, 2017 10:32 pm

Historically LibMaple used to use nops for delay, but either way, using delay is going to waste power.

Leave a Reply

Your email address will not be published. Required fields are marked *