stm32f407 clocked at 8MHz drawing 17mA?

[julian1]

I'm playing with a fairly bare stm32f407 ebay board, and am a bit surprised at the current consumption  - which is higher than I expected at 17mA? Googling shows references to 200-250uA/MHz - but perhaps that's not correct at lower-clock frequencies?

Notes -
- The board is powered directly using only the 3.3V output of the stlink SWD
- The board's smd 3.3V regulator has been desoldered.
- There are two leds - with 1k current limiting resistors - they consume at most 2mA - confirmed by watching the current difference with the led blinking.
- The external oscillator was checked to be 8MHz with an oscilloscope
- current measurements were performed with a 1ohm series resistor, and also directly with meter current range

- The slow-clocking code was hacked together by digging through the libopencm3 examples and source. From reading - the main thing is to configure the system clock to use the external oscillator (hse), and to bypass all the pll stuff. Based on the frequency of the blinking led, I believe it's working correctly.

Code: [Select]

  if(false) {
       
    // works - uses 50mA
    // hse is the external clock
    rcc_clock_setup_hse_3v3(&rcc_hse_8mhz_3v3[RCC_CLOCK_3V3_168MHZ]);
  } else if(false) {
       
    // works - uses 25mA
    // ok 48mhz - ok - and uart appears to work ok - .
    rcc_clock_setup_hse_3v3(&rcc_hse_8mhz_3v3[RCC_CLOCK_3V3_48MHZ]);
  } else if(true) {

    // works - uses 17mA

    // Enable external high-speed oscillator - 8MHz.
    rcc_osc_on(RCC_HSE);
    rcc_wait_for_osc_ready(RCC_HSE);
   
    /* disable high performance mode */
    pwr_set_vos_scale(PWR_SCALE2);
   
    // Select HSE as SYSCLK source.
    rcc_set_sysclk_source(RCC_CFGR_SW_HSE);
   
    // needed?
    rcc_wait_for_sysclk_status(RCC_HSE);
   
    // Set the peripheral clock frequencies used.
    rcc_ahb_frequency  = 8000000;
    rcc_apb1_frequency = 8000000;
    rcc_apb2_frequency = 8000000;
   
    // turn internal clock off
    rcc_osc_off(RCC_HSI);
  }

The only peripheral enabled is for gpio to blink the led,

Code: [Select]

static void gpio_setup(void)
{
  /* Using API functions: */
  rcc_periph_clock_enable(RCC_GPIOE);

  // setup led open-drain
  gpio_mode_setup(GPIOE, GPIO_MODE_OUTPUT, GPIO_OTYPE_OD, GPIO0);
}

Does anyone have experience with expected current consumption? Turning on and using the UART, ADC, DAC only adds a couple more mA.

[krho]

What does the pdf say. There are tables with power consumption at various frequencies and with ART/prefetch enabled disabled

[Kilrah]

Are you really sure you've got the core running at 8MHz?

Datasheet says running at 8MHz from flash with ART enabled and all peripherals disabled is 4mA typical... but max 16mA.
So there may be quite a bit of process variation it seems.

[Kjelt]

I'm playing with a fairly bare stm32f407 ebay board, and am a bit surprised at the current consumption  - which is higher than I expected at 17mA?

I think 17mA is pretty good, compared to a STM8S207 8 bit only that already uses 20mA@16MHz that is darn good for such a powerfull chip.
If you want lower power use the STM32L devices, a bit less performance but if power is the most important requirement that is the way to go.

Datasheet says running at 8MHz from flash with ART enabled and all peripherals disabled is 4mA typical... but max 16mA.
So there may be quite a bit of process variation it seems.

Look at datasheet table 20 it is temperature dependent, 5mA typ @25^oC , 17mA typ @85^oC.
All peripherals off saves 2 mA.

[krho]

I think 17mA is pretty good, compared to a STM8S207 8 bit only that already uses 20mA@16MHz that is darn good for such a powerfull chip.

Hm That's interesting I was looking at STM8S yesterday as a possible keyboard controller and the PDF said a 4mA@3V3 and 16MHz.

[PChi]

Have all the GPIOs got external pull ups or pull downs or are they driven?
Foating GPIOs can increase the current consumption.

[julian1]

Have all the GPIOs got external pull ups or pull downs or are they driven?
Foating GPIOs can increase the current consumption.

The mcpu pins are pulled out to the pcb board headers. They are not externally tied high or low. Only one IO port (E) gets a clock configured for it - and only a single GPIO pin is configured as open-drain for the blinking led.

But I find it interesting that it still consumes 12mA after issuing a halt with openocd that stops the pc. So I wonder what is using that current?

Are you really sure you've got the core running at 8MHz?

I am not confident on the basis of the code. But the observed difference in blinking speed between 48MHz (which is a supported library example) and 8MHz, and also a back-of-the envelope calculation for the instruction cost of the nop loop suggests its right. 

Datasheet says running at 8MHz from flash with ART enabled and all peripherals disabled is 4mA typical... but max 16mA.
So there may be quite a bit of process variation it seems.

Look at datasheet table 20 it is temperature dependent, 5mA typ @25oC , 17mA typ @85oC.
All peripherals off saves 2 mA.

Hmmm, so it's actually in spec - albeit at the max end - and the mcu is not over room temp. It's odd that it's still consuming around 10-12mA with a halt issued.

[Kilrah]

But I find it interesting that it still consumes 12mA after issuing a halt with openocd that stops the pc. So I wonder what is using that current?

Umm that wasn't part of the original description - while connected to the debugger I'd imagine the debug core draws power that wouldn't be used without a PC connection.

[julian1]

But I find it interesting that it still consumes 12mA after issuing a halt with openocd that stops the pc. So I wonder what is using that current?

Umm that wasn't part of the original description - while connected to the debugger I'd imagine the debug core draws power that wouldn't be used without a PC connection.

No. I just remembered it, and thought it may be relevant. I haven't really noticed a difference in current draw when using st-link (when the jtag/swd is active) versus another source. Just tried powering with a bench supply again - and it's 16mA-17mA depending on whether the led is lit.

[TassiloH]

Have you tried to pull all unused GPIOs to a defined level, either externally or by setting them as outputs and outputting 0 or 1 on them? By default they will be inputs and float at an arbitrary level, which might cause extra current consumption in the input circuitry of the pin.

Quote from datasheet:
Additional I/O current consumption is due to I/Os configured as inputs if an intermediate voltage level is externally applied. This current consumption is caused by the input Schmitt trigger circuits used to discriminate the input value. Unless this specific configuration is required by the application, this supply current consumption can be avoided by configuring these I/Os in analog mode. This is notably the case of ADC input pins which should be configured as analog inputs.
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.

[Kjelt]

Hm That's interesting I was looking at STM8S yesterday as a possible keyboard controller and the PDF said a 4mA@3V3 and 16MHz.

Perhaps a different member than the STM8S208's I use, the datasheet says if you run from flash @16MHz from internal osc. it cost you between 8mA and 13mA, and ofcourse I have some pins that are active, should have discounted for that.

[tatus1969]

Have you tried to pull all unused GPIOs to a defined level, either externally or by setting them as outputs and outputting 0 or 1 on them? By default they will be inputs and float at an arbitrary level, which might cause extra current consumption in the input circuitry of the pin.

+1, that would also have been my recommendation. Quiescent current from floating input can be in the milliampere ranges - per pin depending on which controller you look at.

[AndyC_772]

Does the current you're measuring all flow through the CPU, or does it include the current drawn by any other components on the board (like, for example, an external oscillator?)

[andyturk]

Does anyone have experience with expected current consumption? Turning on and using the UART, ADC, DAC only adds a couple more mA.

I've got a home built STM32F405 board that draws 22.5mA blinking two LEDs (only 1msec on time for each) while running the core at 84MHz. So your figures seem high.

Is that a reset button on your board? What's the current draw when you hold the core in reset? On my board it's about 3.5mA.

[julian1]

Have you tried to pull all unused GPIOs to a defined level, either externally or by setting them as outputs and outputting 0 or 1 on them? By default they will be inputs and float at an arbitrary level, which might cause extra current consumption in the input circuitry of the pin.

Quote from datasheet:
Additional I/O current consumption is due to I/Os configured as inputs if an intermediate voltage level is externally applied. This current consumption is caused by the input Schmitt trigger circuits used to discriminate the input value. Unless this specific configuration is required by the application, this supply current consumption can be avoided by configuring these I/Os in analog mode. This is notably the case of ADC input pins which should be configured as analog inputs.
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.

Excellent! All the suggestions to focus on gpio were spot on.

I configured all inputs except the led as analog. It now draws 7mA - with the single power-indicator led - so 6mA at 8MHz. For posterity/searching - the code looks like this (the clock_enable may not be required).

Code: [Select]

static void gpio_setup(void)
{
 
  rcc_periph_clock_enable(RCC_GPIOA);
  rcc_periph_clock_enable(RCC_GPIOB);
  rcc_periph_clock_enable(RCC_GPIOC);
  rcc_periph_clock_enable(RCC_GPIOD);
  rcc_periph_clock_enable(RCC_GPIOE);
  rcc_periph_clock_enable(RCC_GPIOF);
  rcc_periph_clock_enable(RCC_GPIOG);

  // GPIO_MODE_ANALOG - configure pin as analog function following datasheet
  /* 
    See, datasheet,
    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 ....
  */
  gpio_mode_setup(GPIOA, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOB, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOC, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOD, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOE, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOF, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOG, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);

  // change led for open-drain
  gpio_mode_setup(GPIOE, GPIO_MODE_OUTPUT, GPIO_OTYPE_OD, GPIO0);
}

The only problem - the SWD pins have also been re-configured - so now ST-Link is unable to connect - not even while holding down reset.

So I may have bricked the board, unless there's another way to clear the flash.

[julian1]

Ok, SWD is restored by setting BOOT0 to use the internal loader instead of flash.

[Muxr]

Anyone have an explanation as to why it uses so much power when pins are left floating?

Just curious, that's all.

[tatus1969]

Anyone have an explanation as to why it uses so much power when pins are left floating?

Just curious, that's all.

the term to google is CMOS floating input. when the input voltage of a CMOS input floats between the supplies, then both the PMOS and NMOS transistors conduct, creating a short circuit.

[krho]

Ok, SWD is restored by setting BOOT0 to use the internal loader instead of flash.

Can you post the correct code for gpio setup. Too lazy to go digging through the datasheet.

[julian1]

Ok, SWD is restored by setting BOOT0 to use the internal loader instead of flash.

Can you post the correct code for gpio setup. Too lazy to go digging through the datasheet.

That change was only temporary - to let me get back into the device with ST-link and flash a new image.

I've now gone back to pulling the BOOT0 pin to gnd which sets the device to boot from flash. It's the little white jumper in the attachment pic of the board.

My low-power gpio setup now leaves the SWD pins untouched so SWD /gdb can be used - while disabling everything else. The code looks like this,

Code: [Select]

static void gpio_setup(void)
{
  // enable clocks - surprisingly uses less power (7mA versus 12mA) with clocks enabled
  rcc_periph_clock_enable(RCC_GPIOA);
  rcc_periph_clock_enable(RCC_GPIOB);
  rcc_periph_clock_enable(RCC_GPIOC);
  rcc_periph_clock_enable(RCC_GPIOD);
  rcc_periph_clock_enable(RCC_GPIOE);
  rcc_periph_clock_enable(RCC_GPIOF);
  rcc_periph_clock_enable(RCC_GPIOG);

  /*
    - configure pins as analog function following datasheet to reduce power consumption
    - See, datasheet,
    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 ....
  */

  // leave PA13 and PA14 alone - since used for SWD
  gpio_mode_setup(GPIOA, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL & ~ (GPIO13 | GPIO14) );
  // other ports are all analog
  gpio_mode_setup(GPIOB, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOC, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOD, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOE, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOF, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);
  gpio_mode_setup(GPIOG, GPIO_MODE_ANALOG, GPIO_PUPD_NONE, GPIO_ALL);

  // change led for open-drain
  gpio_mode_setup(GPIOE, GPIO_MODE_OUTPUT, GPIO_OTYPE_OD, GPIO0);

  // note - disabling the clocks even after gpio_mode_setup() has been done, still uses more power - 12mA rather than 7mA
}