STM32L011 consumption variation

That's how the internal regulator works.

JW

Thank you for this information.

Is this operation explained in a document (datasheet, Reference guide, ...)?

No, I based my assertion on this. But maybe what you see has a different cause.

JW

Thank's for this information Jan, it looks like what I see.

Another behavior appeared during my tests:

The function executed in RAM is an infinite loop coded with a "while(1){asm("nop");}" and there is no other peripheral activated.

- If there is 0 NOP instruction, the consumption change from 10,42µA to 11,02µA whether 10,7µA average with 0,6µA (5,6%) of variation during a time around 2 minutes 10 seconds.

- If there is 1 NOP instruction, the consumption change from 11,88µA to 12,65µA whether 12,3µA average with 0,77µA (6,3%) of variation during a time around 2 minutes 10 seconds.

- If there are 10 NOP instructions, the consumption change from 9,31µA to 9,78µA whether 9,5µA average with 0,47µA (4,9%) of variation during a time around 1 minute 53 seconds.

There is always cyclic variation in one configuration (between 0,47 and 0,77µA) but there is also a difference between the number of NOP instructions in the infinite loop (between 9,5 and 12,3µA average) and that seems very weird.

Does anybody have an idea about this?

Laurent.

You should go for asm, or more precisely, disasm, for this kind of analysis/discussion.

One possible explanation may be this: the 'L0 has a 32-bit wide FLASH, while instructions are mostly 16-bit wide, some 32-bit.This means two things: there may be a different number of fetches from FLASH for different alignment of the program to 32-bit boundary, and the fetch unit inside the processor swaps the halfwords around differently. Try to move around the code for different alignment.

In real-world code longer than just a couple of bytes, and with multiple jumps and branches, this effect won't be that pronounced probably.

You can also try to play with bits in FLASH_ACR, although they probably will make things worse in case of low-frequency execution.

You can also try to execute from RAM, while disabling FLASH just after loading the code to RAM (using the aptly named RCC_AHBENR.MIFEN).

Usually the recommended mode of operation for lowest consumption is to execute in bursts, at relatively high clock frequency but for a short time, followed by long period of some level of sleep. I have almost no personal experience with low-power applications.

JW

I don't understand why this consumption variation, but thanks for your help Jan.

Note 1: The STM32 is in LowPower Run mode with MSI clock and executes in RAM (Flash memory in power-down)

Note 2: I need an operating frequency of 65536Hz to generate a pattern on a GPI/O continuously (GPI/O disabled for this test, and replace by infinite loop below).

Note 3: The infinite loop is executed with few "nop" (16 bits instruction) and a "branch" (16 bits instruction)

Laurent.

Sounds like a task for timer and DMA, with processor in sleep, but not in 'L0.

Determining where power goes in circuits with literally millions of transistors is next to impossible. ST will happily fire up their inordinately expensive simulators if you provide enough incentive expressed in $M++ of purchases. Other than that, we can make only rough guesses. The power consumption is roughly given by the number of switching transistors times the load they are driving. Changing address/data on a bus means more consumption than say adding two numbers using the miniscule transistors of the processor core. Incrementing address across a boundary where many lines switch from 0 to 1 or vice versa means more consumption than to stay within addresses where only the LSB changes. The case with many NOPs may have lower consumption simply due to the fact that executing NOP less transistors are exercised in the processor than with the jump.

JW