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 24, 2015 at 16:03

Try to measure it while holding it in reset.

JW

[Tesla DeLorean]

Posted on February 24, 2015 at 16:15

Try to measure it while holding it in reset.

Not sensing an STM32 origin either...

[rizwin]

Posted on February 24, 2015 at 16:27

Idd when in reset is constant.

[waclawek.jan]

Posted on February 24, 2015 at 16:39

Well, that sounds surprising.

What is the absolute value of current consumption and what is the amplitude of the ''sawtooth''? The period is around 55 seconds, correct? If I understand what you wrote about your code correctly, the ADC module is running, but conversion is not started if you placed an empty while(). What happens, if you omit the ADC initialization altogether and place only an empty while()? [EDIT] on second reading of your initial post, it appears that this is exactly what you've done already... that would leave HSE+PLL as the only possible source of disturbance(?) Try various clock options (HSI alone, HSI+PLL, HSE alone, HSE+PLL, various PLL settings, external clock), any change? Another idea, can't this be some artefact from the used power source under the increased load when PLL is running? Try to add some artifical load while mcu is in reset. Btw. did you disconnect the SWO lines from the debugger 'F103? JW

[rizwin]

Posted on February 24, 2015 at 17:16

Hi waclawek.jan,

The absolute value of current varies depending on what peripherals I enable. Currently, when no pheripherals are enabled, the current consumed is roughly 3.15mA with amplitude of 72µA for the saw-tooth. On the scope (Rigol DS1204B) the blue signal is a measurement with a current probe (Agilent 2005, PowerSupply N2775A) , the factor is 40 and the result is in mA. Yes, the period is 55 seconds. The ADC is not even initialized! It is like:

int main(void)
{
while(1);  ... 
}

Only the startup_stm32f30x.s code should run. I just took a sample project from the ST example as I have seen the same effect in my code which is an entirely different project. I've also made the measurement without ST-LINK (please see the picture attached). ________________ Attachments : 2015-02-24_17-09-34.514.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1J6&d=%2Fa%2F0X0000000bl7%2FYDovbGur7k58GXoviIuv4Tjoad6AJ3fqrTK4me_OlTs&asPdf=false

[waclawek.jan]

Posted on February 24, 2015 at 17:32

Thanks for the info.

Please see my additional comments under [EDIT] in my previous post; it appears you read that post before I've added them. Jan

[rizwin]

Posted on February 24, 2015 at 18:08

Hi Jan,

Yes,  HSE+PLL is the only possible source of disturbance as far as I know. Currently, We are using 72MHz and we are not interested in other clocking options for my application. I'll try the same with the STM32F4 dicovery board and let you know the result. Thanks. Riz

[waclawek.jan]

Posted on February 24, 2015 at 18:31

> Yes,  HSE+PLL is the only possible source of disturbance as far as I know. Currently, We are using 72MHz and we are not interested in other clocking options for my application.

I'd still try to verify it's the HSE+PLL; and whether it's HSE or PLL. I'd also try to use different PLL settings - there are several settings to achieve the same frequency. I'd also experiment with the AVDD/AGND decoupling and ground distribution schemes, as all these might or might not impact the PLLs behaviour (a thick lose wire is your friend ;) ). I'd also experiment with the supply voltage. Jan

[rizwin]

Posted on February 25, 2015 at 15:16

>>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'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'd also experiment with the AVDD/AGND decoupling and ground distribution schemes, as all these might or might not impact the PLLs behaviour (a thick lose wire is your friend ;) ). I'd also experiment with the supply voltage. We are using AVDD/AGND on our application and still we see the same behavior. We have tried different power supplies as well.