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 ]

[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'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

[jj]

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'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.

[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 ]

[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

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.

[jj]

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!