Current consumption behaves like saw-tooth

[rizwin]

Posted on February 24, 2015 at 15:13

I measured the current consumption of STM32F3 discovery board from its Idd pin and I always see the current consumption decreasing with time over a period of 50-60 seconds and then shoots up to the initial value. I used a standard example from ST STM32F3-Discovery_FW_V1.1.0\Project\Peripheral_Examples\ADC_Example and tried putting a while(1); loop as the first line of main().

I have found the same effect on STM32f373 MCUs as well.

Can someone tell me the reason for that and how to rid of this saw tooth behaviour?

Please find attached the screenshot of the behaviour from the oscilloscope.

#stm32f3 #stm32f3discovery

[rizwin]

Posted on February 25, 2015 at 16:02

The system clock is set on 8MHz for both HSE and HSI without PLL. (PLL is OFF). The settings I tried (HSE+PLL, HSE alone, HSI alone) are added as attachments.

I tested the HSE+PLL (72MHz) with STM32F4 discovery board and I don't see any sawtooth curve there. The current consumption is constant in that one.

Riz

________________

Attachments :

system_stm32f30x_HSE_8MHz.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1J1&d=%2Fa%2F0X0000000bl4%2FJaWKeefejyabjIRoHEvAyNolvpGvf7Ahj_I.2k.QyEc&asPdf=false

system_stm32f30x_HSEPLL_72MHz.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Iw&d=%2Fa%2F0X0000000bl5%2F4JHJLOyOfcitkANNszYHIfAo4878gAwXcZ2MAy.h3zg&asPdf=false

system_stm32f30x_HSI_8MHz.c : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Ir&d=%2Fa%2F0X0000000bl1%2FSJZ5kUfuFBdDjsC2m.Dk7vtvxCwxpG4jrIqmBUr2CqQ&asPdf=false

[waclawek.jan]

Posted on February 25, 2015 at 16:53

The HSE+PLL setting appears to set PLL to 8MHz and not to 72MHz.

system_stm32f30x_HSEPLL_72MHz.c:

/* PLL configuration */ RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL)); RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_PREDIV1 | RCC_CFGR_PLLMULL2); RCC->CFGR2 &= (uint32_t)((uint32_t)~(RCC_CFGR2_PREDIV1)); RCC->CFGR2 |= (uint32_t)(RCC_CFGR2_PREDIV1_DIV2);

Can you please confirm (possibly by directing sysclk to MCO)?

If so, what happens if the PLL is set to real 72MHz or any higher frequency?

In any case, it appears that PLL itself is innocent. This may be related to any peripheral which is after reset on, or which has a clock source independent from the clock tree (FLASH charge pump?, IWDG); or I am overlooking something.

I am afraid only ST could answer this. Is it really that important for your application, a cca 2% change in current consumption?

JW

[rizwin]

Posted on February 25, 2015 at 18:41

Hi Jan,

Thanks for pointing out the error. It should be

    /* PLL configuration */

    RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE | RCC_CFGR_PLLMULL));

    RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_PREDIV1 | RCC_CFGR_PLLXTPRE_PREDIV1 |

RCC_CFGR_PLLMULL9

); to get 72MHz output when using 8 MHz crystal.

>> Is it really that important for your application, a cca 2% change in current consumption?

We've assumed a stable voltage, like by F4 which is not the case. Could the internal DAC/ADC be influenced by that? We use now external ones, but it takes place on the board.

We are working on new HW design but a SW solution is prefered.

Anyway, thanks for your help. We'll get in touch ST.

Riz

[Amel NASRI]

Posted on March 03, 2015 at 11:56

Hello Riz,

What you are seeing as behavior on STM32F3 parts is the expected one. 

It is the impact of the internal regulator used to supply the internal 1.8 V digital power. The internal VDD will be 1.8V +/-8%.

If you will be using RegOff parts (STM32F3x8), you will not see such behavior in the IDD values which will be constant.

-Mayla-