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

[waclawek.jan]

Posted on February 25, 2015 at 15:44

>>I'd still try to verify it's the HSE+PLL; and whether it's HSE or PLL.

> I am using the

http://www.st.com/web/en/catalog/tools/PF258143

to generate C > code for different clocking options. I have tried both HSE and HSI with 8MHz and I still see > the same bhaviour with a period of 75 seconds. I don't understand what was your setting - do you mean, system clock set on HSE or HSI, both 8MHz? PLL on or off? >>I'd also try to use different PLL settings - there are several settings to achieve the same frequency. > Is it possible to try different PLL settings with the same config tool? If not, how can I acheive it? I don't use that tool. It is easy to get a grip on the RCC settings directly changing the registers - see RCC chapter in UM, mainly RCC_CR and RCC_CFGR register fields. JW

[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=falsesystem_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=falsesystem_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-