STM32F103ZET6 not meeting published power specs?

[burk]

Posted on January 19, 2010 at 15:22

STM32F103ZET6 not meeting published power specs?

[burk]

Posted on May 17, 2011 at 13:34

We've gotten the STM32F103ZET6 on the alpha board, gotten the peripherals to come up, and everything's looking rosy so far, except for one, show-stopping problem: Power consumtion is double the published specs when running at the base frequency of 8 Mhz.

We've been struggling with this problem for three weeks so far and ST's only referred me back to the datasheet.

My application is a battery powered data acquisition system for long term field measurements. According to the datasheet, with all peripherals on, power should be approximately 8 to 9 milliamps. We run the clock at base frequency until USB sense is activated. At that time, the PLLMULT is adjusted upwards so that we can interface to the host computer via USB. Power is not a problem when running USB, but at base frequency in standalone mode, the power is ''a blazing'' 17 mA, nearly double the published power specs. This is a show-stopper in that there is no power left over to power the sensors, run the ADCs, or write data to external memory. Those extra eight mA will cut my battery life nearly in half.

Can anyone point me in some directions as to where I can look, or otherwise prove /disprove the issue? It seems that any time we place code into the main execution loop on the micro, power jumps considerably. If we write a Do..While and put nothing inside, it appears that power will stay down. Add a wait state inside the loop, and power goes up. The same test code on the eval board stays stable at 8 mA.

Power consumption is identical, whether or not we run the code on a populated board or one which has been stripped of all components except the 3.3V regulator, the crystals, and the microprocessor itself. Therefore the power appears to be consumed not in any incompatability with external hardware, but internally in the micro itself. I'm starting to think the STM32F103ZET6 does not comply to the published power specs. Our STM32F103X evaluation board *will* run at 8mA, but when we port the code over to the ZET6, power doubles.

Configuration is as follows:

STM32F103ZET6 running at 20 degrees C

8 Mhz crystal external clock

PLLMULT = 2 (lowest setting)

FSMC enabled

USB unplugged

ADC configured but not sampling yet

Simple test loop , a Do_while, and a wait state in the main program.

Current is 17 mA.

Page 39 of the data sheet claims it should be 8 to 9 mA.

----

void CLOCK_Initialize(uint32_t RCC_PLLMul)

{

/* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ------------*/

/* RCC system reset(for debug purpose) */

RCC_DeInit();

/* Enable HSE */

RCC_HSEConfig(RCC_HSE_ON);

/* Wait till HSE is ready */

HSEStartUpStatus = RCC_WaitForHSEStartUp();

if(HSEStartUpStatus == SUCCESS)

{

/* Enable Prefetch Buffer */

FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);

/* Flash 2 wait state */

FLASH_SetLatency(FLASH_Latency_2);

/* HCLK = SYSCLK */

RCC_HCLKConfig(RCC_SYSCLK_Div1);

/* PCLK2 = HCLK */

RCC_PCLK2Config(RCC_HCLK_Div1);

/* PCLK1 = HCLK/2 */

RCC_PCLK1Config(RCC_HCLK_Div2);

/* PLLCLK = 8MHz * 9 = 72 MHz */

RCC_PLLConfig(RCC_PLLSource_HSE_Div2, RCC_PLLMul);

/* ADCCLK = PCLK2/4 */

RCC_ADCCLKConfig(RCC_PCLK2_Div4);

/* config the system clock to output to the MCO output pins */

RCC_MCOConfig(RCC_MCO_PLLCLK_Div2);

/* Enable PLL */

RCC_PLLCmd(ENABLE);

/* Wait till PLL is ready */

while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET)

{

}

/* Select PLL as system clock source */

RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);

/* Wait till PLL is used as system clock source */

while(RCC_GetSYSCLKSource() != 0x08)

{

}

}

/* Enable GPIOA, GPIOB, GPIOC, GPIOD, GPIOE, GPIOF, GPIOG and AFIO clocks */

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB |RCC_APB2Periph_GPIOC

| RCC_APB2Periph_GPIOD | RCC_APB2Periph_GPIOE | RCC_APB2Periph_GPIOF | RCC_APB2Periph_GPIOG

| RCC_APB2Periph_AFIO, ENABLE);

/* Enable the FSMC clocks */

RCC_AHBPeriphClockCmd(RCC_AHBPeriph_FSMC, ENABLE);

/* TIM1 Periph clock enable */

RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM1 | RCC_APB2Periph_ADC1 | RCC_APB2Periph_ADC2 |

RCC_APB2Periph_ADC3 | RCC_APB2Periph_GPIOC, ENABLE);

}

[ This message was edited by: burk on 16-12-2009 19:12 ]

[burk]

Posted on May 17, 2011 at 13:34

I'm pretty sure we've got the GPIOs covered. However I have some No-connects that are configured as outputs. I can try reconfiguring them as inputs with weak pulldown resistor enabled and see if it makes any difference. I'm not expecting to see much, if any change in power, but I'll give anything a go at this point.

--

IO map for STM32F103 in EDR3V7 Alpha board

Port Name Port Description IO INITIAL STATE PORT CONFIG

PA0 CS1_CH1 on ADC1 INPUT ANALOG_IN

PA1 CS1_CH2 on ADC2 INPUT ANALOG_IN

PA2 CS1_CH3 on ADC3 INPUT ANALOG_IN

PA3 CS3_CH1 on ADC1 INPUT ANALOG_IN

PA4 DAC1 OUTPUT DISABLE DISABLE

PA5 DAC2 OUTPUT DISABLE DISABLE

PA6 CS4_CH1 on ADC1 INPUT ANALOG_IN

PA7 CS4_CH2 ON ADC2 INPUT ANALOG_IN

PA8 BAT_INUSE/CLKFRQOUT IO

PA9 USB_DISC IO

PA10 USB_SENSE IO

PA11 USBDM IO

PA12 USBDP IO

PA13 JTMS-SWDIO IO

PA14 JTCLK-SWCLK IO

PA15 JTDI IO

PB0 PBSW INPUT WEAK PULLUP

PB1 ADC_TEMP2 on ADC1 INPUT ANALOG_IN

PB2 JTAG_BOOT1 IO

PB3 JTDO IO

PB4 JNTRST IO

PB5 NC OUTPUT DISABLED DISABLED

PB6 SCL IO HIGH PUSH/PULL

PB7 SDA IO HIGH PUSH/PULL

PB8 CS1_CCS OUTPUT HIGH OPEN DRAIN

PB9 CS2_CCS OUTPUT HIGH OPEN DRAIN

PB10 CS3_CCS OUTPUT HIGH OPEN DRAIN

PB11 CS4_CCS OUTPUT HIGH OPEN DRAIN

PB12 CS1_BRPW OUTPUT LOW PUSH/PULL

PB13 CS2_BRPW OUTPUT LOW PUSH/PULL

PB14 CS3_BRPW OUTPUT LOW PUSH/PULL

PB15 CS4_BRPW OUTPUT LOW PUSH/PULL

PC0 CS2_CH1 on ADC1 INPUT ANALOG_IN

PC1 CS2_CH2 on ADC2 INPUT ANALOG_IN

PC2 CS2_CH3 on ADC3 INPUT ANALOG_IN

PC3 CS3_CH2 on ADC2 INPUT ANALOG_IN

PC4 ADC_AVCC on ADC1 INPUT ANALOG_IN

PC5 ADC_HUM on ADC2 INPUT ANALOG_IN

PC6 AVCC ON/OFF OUTPUT LOW PUSH/PULL

PC7 TRIG_IN INPUT FLOATING

PC8 TRIG_OUT OUTPUT HIGH OPEN DRAIN

PC9 CS1_SEDE OUTPUT LOW PUSH/PULL

PC10 CS2_SEDE OUTPUT LOW PUSH/PULL

PC11 CS3_SEDE OUTPUT LOW PUSH/PULL

PC12 CS4_SEDE OUTPUT LOW PUSH/PULL

PC13 TAMPER-RTC NOCONNECT NOCONNECT

PC14 OSC32_IN

PC15 OSC32_OUT

PD0 FSMC_D2 : DQ2 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PD1 FSMC_D3 : DQ3 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PD2 LED_ARMED OUTPUT LOW PUSH/PULL

PD3 NC OUTPUT DISABLED DISABLED

PD4 FSMC_NOE : OE# OUTPUT HIGH PUSH/PULL

PD5 FSMC_NWE : WE# OUTPUT HIGH PUSH/PULL

PD6 NC OUTPUT DISABLED DISABLED

PD7 FSMC_NE1 : BANK 0: G2A# OUTPUT HIGH PUSH/PULL

PD8 FSMC_D13 : DQ13 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PD9 FSMC_D14 : DQ14 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PD10 FSMC_D15 : DQ15 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PD11 FSMC_A16 : A15 OUTPUT HIGH PUSH/PULL

PD12 FSMC_A17 : A16 OUTPUT HIGH PUSH/PULL

PD13 FSMC_A18 : A17 OUTPUT HIGH PUSH/PULL

PD14 FSMC_D0 : DQ0 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PD15 FSMC_D1: DQ1 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE0 FSMC_NBL0 : LB# OUTPUT HIGH PUSH/PULL

PE1 FSMC_NBL1 : UB# OUTPUT HIGH PUSH/PULL

PE2 FSMC_A23 : A22 OUTPUT HIGH PUSH/PULL

PE3 FSMC_A19 : A18 OUTPUT HIGH PUSH/PULL

PE4 FSMC_A20 : A19 OUTPUT HIGH PUSH/PULL

PE5 FSMC_A21 : A20 OUTPUT HIGH PUSH/PULL

PE6 FSMC_A22 : A21 OUTPUT HIGH PUSH/PULL

PE7 FSMC_D4 : DQ4 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE8 FSMC_D5 : DQ5 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE9 FSMC_D6 : DQ6 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE10 FSMC_D7 : DQ7 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE11 FSMC_D8 : DQ8 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE12 FSMC_D9 : DQ9 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE13 FSMC_D10 : DQ10 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE14 FSMC_D11 : DQ11 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PE15 FSMC_D12 : DQ12 IO PUSH/PULL WEAK PULLDOWN IN INPUT STAGE?

PF0 FSMC_A0 OUTPUT DISABLED DISABLED (Note: We were using last year's datasheet/reference manual for 16-bit memory addressing(oops!) It'll be fixed on production system. We didn't know about ST's internal bit-shift trick until half our memory came up missing.

PF1 FSMC_A1 LSB A0 OUTPUT HIGH PUSH/PULL

PF2 FSMC_A2 : A1 OUTPUT HIGH PUSH/PULL

PF3 FSMC_A3 : A2 OUTPUT HIGH PUSH/PULL

PF4 FSMC_A4 : A3 OUTPUT HIGH PUSH/PULL

PF5 FSMC_A5 : A4 OUTPUT HIGH PUSH/PULL

PF6 CS3_CH3 on ADC3 INPUT ANALOG_IN

PF7 ADC_VBAT on ADC3 INPUT ANALOG_IN

PF8 DVCC_LDO INPUT

PF9 AVCC_LDO INPUT

PF10 CS4_CH3 on ADC3 INPUT ANALOG_IN

PF11 NC OUTPUT DISABLED DISABLED

PF12 FSMC_A6 : A5 OUTPUT HIGH PUSH/PULL

PF13 FSMC_A7 : A6 OUTPUT HIGH PUSH/PULL

PF14 FSMC_A8 : A7 OUTPUT HIGH PUSH/PULL

PF15 FSMC_A9 : A8 OUTPUT HIGH PUSH/PULL

PG0 FSMC_A10: A9 OUTPUT HIGH PUSH/PULL

PG1 FSMC_A11 : A10 OUTPUT HIGH PUSH/PULL

PG2 FSMC_A12 : A11 OUTPUT HIGH PUSH/PULL

PG3 FSMC_A13 : A12 OUTPUT HIGH PUSH/PULL

PG4 FSMC_A14 : A13 OUTPUT HIGH PUSH/PULL

PG5 FSMC_A15 : A14 OUTPUT HIGH PUSH/PULL

PG6 NC OUTPUT DISABLED DISABLED

 

PG7 NC OUTPUT DISABLED DISABLED

PG8 LED_USB OUTPUT LOW PUSH/PULL

PG9 FSMC_NE2 OUTPUT HIGH PUSH/PULL

PG10 FSMC_NE3 OUTPUT HIGH PUSH/PULL

PG11 NC OUTPUT DISABLED DISABLED

PG12 FSMC_NE4 OUTPUT HIGH PUSH/PULL

PG13 FSMC_A24 : A23 OUTPUT HIGH PUSH/PULL

PG14 FSMC_A25 : A24 OUTPUT HIGH PUSH/PULL

PG15 LED_ACT OUTPUT LOW PUSH/PULL

[domen2]

Posted on May 17, 2011 at 13:34

Floating GPIOs come to mind.

They should either be output set to some value, pull-up/down input or analog input.

More info is found on this forum, there's also a FAQ entry, I think.

[burk]

Posted on May 17, 2011 at 13:34

I'll scope the regulator. Then I'll bypass it and run 3.3VDC if I don't see anything. Crystal swapping might be problematic due to the SMC nature of the crystal. I'm using an Abracon ABM3B-series with 10 pf capacitors. It's a 10uW typ, 100uW max. crystal with an max ESR of 200 ohms. Just 5mm long, it's a bitty lil' thing.

[jj_it]

Posted on May 17, 2011 at 13:34

Long shot - perhaps worthwhile -

swap the xtal & related caps from eval board (runs @ lo power) to your excessive current board.

would also look very closely @ 3V3 regulator - perhaps its not truly stable.

[burk]

Posted on May 17, 2011 at 13:34

I must apologize ahead of time for my ignorance, but I do not quite understand. How is it, that having my peripherals enabled, (FSMC, ADC, and USB) fall outside of the specified current of 8 mA of the data sheet? Even at its worst case, the data sheet plainly states in page 51, table 18, ''All Peripherals Enabled, running code from FLASH'' a typical current of 7.2 mA + (0.8mA per ADC * 3 ) = 9.6 mA for this series of microprocessor.

Please forgive me but this is a CRITICAL design requirement, and for the last six weeks I have gotten nowhere. I have attempted to lodge a customer service request (on December 10th) and received from a Mr. Nicolas Fillon, of ST, an answer that states:

''The consumption will depend at what speed you run internally.

Please see the power consumption figures:

http://www.st.com/stonline/products/literature/ds/13587.pdf, on page 39.''

This is the extent of the service that I have received thus far from ST. Subsequent emails to Mssr. Fillon have gone unanswered.

I have requested help through our rep at Arrow Electronics, who tried to refer our problem to their ST FAE support line, and again, thus far, we have heard nothing.

I've staked the whole development of our new design around the ST microprocessor, believing in ST's reputation to produce quality components, and thus far, it appears I may have made a critical,very expensive design killing mistake in choosing ST as the basis of the platform. Please tell me this isn't so!

I need those nine milliamps back to make this project work. I can try a different chip: The STM32F103ZCT6, with a reduced flash and RAM capacity, but beyond that, I am really at a loss as to what else to try.

[16-32micros]

Posted on May 17, 2011 at 13:34

Hi Burk,

In your application, many peripherals are clocked and Enabled ( FSMC, ADC and USB) which is not the case as stated in our data-sheets when we specify the 8mA ; in addition you are executing a empty while(1); Try to put inside the main loop ( _WFI() instruction to enter Sleep mode) This will stop the CPU).

Let me know if you need more hints... :)

Cheers,

STOne-32.

[ This message was edited by: STOne-32 on 22-12-2009 21:29 ]

[burk]

Posted on May 17, 2011 at 13:34

Okay, I've checked the regulator, and there's no oscillation in there - Rock solid. Then I bypassed the regulator and input 3.30 VDC, and again, so no change. I'm running 17 mA at 8 Mhz with a simple ''blink the LED'' program. (The LED's have been removed to limit power) As I bump the PLLMULT to yield higher clock frequencies, power rises as expected, until at full clock speed 72Mhz we draw 75 mA.

According to table 15, page 45 of the STM32F103ZE datasheet, 8Mhz should yield a MAXIMUM (temp @ 85 deg C) of 9 mA at 8 Mhz, and 66 mA at 72Mhz.

So, it would appear we are continuously above the specs by a constant of 8 to 9 milliamps, regardless of the clock speed. Note that if we go by table 18, as found on page 51, at ambient temperature, a typical power consumption should be 7.2 mA and 51mA respectively. Thus, we're probably closer to 10 mA and 24mA too high respectively!

I'm using a Simson model 373A current meter, not much to go wrong with that simple analog guy. But just in case, I calibrated it, and the currents above are accurate. It's inline with the input power. Input power is 5V to the regulator, 3.30 out of the regulator.

Anybody have any other suggestions?

[ This message was edited by: burk on 22-12-2009 21:05 ]

[burk]

Posted on May 17, 2011 at 13:34

Will give your suggestions a try after the new year, JJ.

Thanks.

[jj_it]

Posted on May 17, 2011 at 13:34

I don't have the answer(s) you seek - perhaps STOne-32's suggestion was missed - and it should definitely help you.

He has asked you to ''put the MCU to sleep'' for the maximum time your process will allow. Have you looked at this option adequately? By reducing the ''on'' duty cycle you will definitely reduce your power demands.

Do turn off as many clocks and enables as possible - you need to give ''luck'' a chance to fall on your side.

Further - suggest that you create a minimal dummy Ap - and see how/if clocking and enabling different devices affects current draw. Can't recall if this behavior occurs across multiple boards - this should be checked/confirmed.

(I'm not near our STM32 boards or I would try such tests for you - maybe I've hit on something that (while under great pressure) you've not fully considered/implemented.) Do try to devise a way to maximize MCU's sleep!