Microcontroller current consumption in RESET

[brumbarchris]

Hello all,
We have a small board designed around the STM32F469VIT6. Trying to characterize our circuits, we started to measure the current consumption of the board with various portions of our circuit turned ON or OFF. Eventually we ended up with just the microcontroller running and everything turned OFF. Current draw in this case is some 80mA. Next step was to reset the micro (there is a dedicated button on the board for that). Expectation was to see current close to 0, some 10s of microamps...but nope! We got a whooping 10...13mA current draw.

Eager to determine the cause we started to chase various leakage paths, without much success. Frustrated, I decided to sacrifice a board and I started to take down the ICs one after the other, but the stubborn consumption was still there. After removing all the ICs I did the same for passives, but still 10...13mA consumption.

Eventually I ended up with just the microcontroller on the board and its necessary decoupling capacitors. I supply it directly with 3.3V from a lab power supply. And yes, the 10...13mA was still there, slowly continuously drifting up and down between these two values. At this point I took a break and investigated the problem theoretically a bit. I came across this post on the STM forum, which made some sense:
https://community.st.com/s/question/0D50X00009XkddqSAB/stm32f401-power-consumption-in-reset

The pins being configured as inputs during reset could indeed lead to increased consumption, but... really, 10mA seems quite too much even for that. The flash being programmed or erased did not make any difference (initially I thought there might have been some RTC running or something like that but obviously, this is not the case)

So I decided to erase the flash and connect all IO pins to GND (I did the flash erasing to make sure no pin is configured as output high by a running software, when out of reset). After connecting all IO pins to GND, I got the current consumption in RESET down to 7mA. Better, but still 10 times higher than what I expected (after all, there are some low power modes in which the micro is running, and for which the datasheet advertises below 1mA of current draw).

There must be some other cause than the IO pins for this consumption. If I measure the VCAP1 and VCAP2 pins I see 1.12V while in RESET, whereas the normal value for running mode is 1.32V. This suggests me that the internal regulator is ON during RESET, but in Power Scale 3, as opposed to Power Scale 1 (see Attachment2.png, screenshot from Operating conditions in datasheet). If the internal voltage regulator is ON, a hole lot of other things might be ON, too. But I cannot determine what sections are ON during RESET, from the datasheet. And as acknowledged in the post from the ST forum, the current consumption in RESET is not specified in the datasheet either.

The internal pull-up of the micro on the NRST pin is in the range of 40kOhm, so that is not the cause for this large current consumption.

What else could I investigate?

I have placed a schematic of what's left on the board in Attachment1.png. Note that by now the IO pins (and also the oscillator pins) are connected to GND. I have left the BOOT pins connected to GND through the pull-down resistors.

Best regards,
Cristian

[TomS_]

Are they genuine STM32's purchased from a reputable source?

IIRC I saw a thread some time back where someone had a similar problem - higher than expected current draw.

I believe it turned out the parts were fakes, and simply didnt meet the quoted specs of a genuine unit.

[brumbarchris]

They are genuine parts, we got them through a fast-track directly from ST.

Thing is, in this case there are no "quoted specs" for the current consumption in RESET. So I just benchmarked it against my (and my colleagues') expectations: below 1mA

[Kleinstein]

There is a chance that some internal input are still at an undefined state. The reduced current from some  10 mA down to 7 mA with the pins connected to ground could be a point in that direction. Ideally this should not happen, and the µC should start in a pretty low power case, but it looks like things are not ideal here. A drifting current also points to something like an open / undefined input.

[SiliconWizard]

I've never used this particular MCU, but others from ST. And from other vendors. And as a general rule, it's not at all uncommon that the power draw when the MCU is held in reset be much higher than when in any low-power mode, for instance. 10 mA doesn't look like excessively weird here.

I tried to find any information in the datasheet regarding power draw in reset, and found nothing. So I'm unable to tell you if what you get is within specs or not. But point is, it may be.
(But if anyone can find this info, please share!)

[rstofer]

The I_RUSH current is 160-200 mA according to page 97 of the datasheet.  Maybe a significant current flows until the CPU comes out of reset.  I didn't find an actual Reset current spec.

https://www.st.com/resource/en/datasheet/stm32f469vi.pdf

[thm_w]

Checked a F103 here and its less than 2mA in reset, but nothing external is connected and this is quite a different micro.

As SiliconWizard said, get it into sleep or low power mode and measure again, ideally with inputs set to analog or pulled down.

[coppice]

I am not that familiar with STM's MCUs, but with most MCUs you need to be really careful to get the lowest current draw they are capable of. Just what does the documentation say about the state of all the pins while the chip is in reset? Does the chip even have well defined states for all the pins while it is in reset, or does it start to tidy them up as it comes out of reset. What are all those pins connected to? If some pins are in odd states, what might they be drawing through whatever is connected to them?

[brumbarchris]

Hello everybody, thank you for your replies.

Just to reiterate: we are not trying to get the lowest current consumption of this micro. We are just surprised that the current consumption in RESET mode is rather high. But by now, it is obvious that in RESET mode the microcontroller is not in a low-power state. Unfortunately, the datasheet mentions nothing about current consumption in RESET and based on the STM reply in their forum thread I have linked in my original posting, it seems they are keeping that out on purpose.

The IO pins are set to input mode in RESET, and by now I have all IO pins grounded (either directly or through some pull-down resistors (the two BOOT pins)). This results in 7mA of current consumption (not fluctuating anymore).

Nevertheless, the observation that we have made, as stated in the original post, is that the internal voltage regulator stays ON. during reset. And consequently, many other things are probably still ON, too; but there is not much information in the datasheet regarding what stays on and in what mode, during RESET.

I have already replaced the microcontroller once, on this board which we are investigating, in order to rule out a specifically faulty part. Current consumption results are the same also with the new instance of the micro.

Regards,
Cristian

[hans]

I also typically like to observe/understand current consumption of boards during various phases of board bring-up, as the current consumption (although aliased by all active components on the board) can give hints to what state components are in (and if there could be a hidden fault, like shorted I/O pins).

And I agree with your observations of mA-level current draw while held in reset. It is especially noticeable when working on low power devices (STM32L). I had a project where the maximum continuous current draw wouldn't even exceed 50uA, so seeing spikes of almost 2mA was very obvious when resetting the device manually (e.g. pull RST low with tweezers).

I think it is because default bits are loaded into all flipflops, including those responsible for e.g. clock/power gates to components that are needed to boot the chip (oscillator, boot ROM, power regulators, system buses).

Perhaps discrepancies you saw during testing was actually caused by erratic I/O current. It typically requires some configuration to get micros into the (repeatable) low power state. You don't want any input pins floating for example, as they can start to draw excessive current.

[brumbarchris]

Yep, and spikes of current at RESET would be something that would pass as acceptable in my eyes, ST actually documents some inrush current values when going into or out of reset.

But what we see now are 7mA of rather continuous current being drawn by the micro. An this is quite much, but I guess that as long as current consumption during RESET is not documented in the datasheet, I cannot say the part is not meeting any specifications. Besides, it could also be that we are missing something silly, something maybe caused by ourselves on this particular board...

Regards,
Cristian

[SeanB]

Very likely that in reset every on chip peripheral is both being enabled and supplied with whatever clock there is, either internal or crystal, so they all are able to run through their internal state machine states and settle down in a known configuration, clocks enabled and all parts running. Your current consumption would be high there, but if you use a sleep command then all internal peripherals that are not totally essential to the chip coming back from sleep will have the clock removed and the data paths isolated, except for peripherals that can operate without the CPU intervention, like prescalers, PWM and dividers, that are all able to provide an interrupt to bring the CPU back to the next instruction after the sleep one.

[hans]

The inrush current is not the same as the continuous current draw during reset. The inrush current is transient, and probably from the capacitors of the voltage regulator ramping, as it specifies it occurs at POR (cold boot) but also from leaving standby (voltage regulators start up again).

The STM32F4xx often has 2x 2.2uF VCAP1/2, which are charged to 1.2V. So: C=Q/V, with V=1.2V and C=2*2.2uF, then Q=5.28uC. Not sure why the datasheet uses the letter E for charge.. but it's very close to their 5.4uC max in-rush "energy".

The continuous current draw is unfortunately not documented, however, for convenience sake I would estimate it to be roughly equivalent as the current consumption the chip has when it just boots up. In that case a STM32F4xx runs from HSI (16MHz), then it's current consumption is in the order of 4..7mA (all peripherals disabled/enabled, respectively). That sounds about the same values as you measured.

[SiliconWizard]

Current draw in reset is something rarely documented for MCUs. Whether on purpose or not. I don't know. I've seen that documented only for a few.

This is something to keep in mind. Some people may be tempted, in a given system, to hold the MCU in reset when not in use (for any reason), thinking it will draw only a minimal amount of current. But that's almost never the case. So your best bet is to have the MCU go in a low power mode if you want to achieve the same - possibly the lowest power mode if that's your goal. Alternatively, you can of course also add a power switch to switch it off completely.

[harerod]

What SiliconWizard wrote.

Let me add - there are devices where the permissible reset duration is actually limited by the datasheet.
I recently had a look at a TI DSP where extended reset times were listed as harmful.

Once I had to respin a design, where the reset signal form didn't fit. In that particular case the rise time was too short. The designer (via several layers of support) admitted that a sequence of things happened at different input levels. So if you see a weird reset circuit with 10µF at the reset pin on an eval board - there might be an actual (undocumented) reason for that.
Edit: typo

[PCB.Wiz]

Just to reiterate: we are not trying to get the lowest current consumption of this micro. We are just surprised that the current consumption in RESET mode is rather high. But by now, it is obvious that in RESET mode the microcontroller is not in a low-power state. Unfortunately, the datasheet mentions nothing about current consumption in RESET and based on the STM reply in their forum thread I have linked in my original posting, it seems they are keeping that out on purpose.

Yes, that's quite common.
MCU designers generally do not consider RESET to be a long term state, so they are lazy about defining what power needs are.
The energy needed to exit reset may matter to some,  as some MCUs have long startup timers to allow things to settle, but that's not great for energy use.
Some MCUs run a startup INIT microcode during reset, at whatever the default clock is, so they do not target low power.

[brumbarchris]

Some people may be tempted, in a given system, to hold the MCU in reset when not in use (for any reason), thinking it will draw only a minimal amount of current.

You just described me perfectly!

Regards,
Cristian

[wek]

As others said, a couple of mA is maybe surprising but not unexpected. The processor's clock is apparently not gated by Reset, and it may quite well be that processor actually executes code from internal memory. Also ARM materials list reset as one of the exceptions (interrupts).

The default system clock is 16MHz HSI, and while the consumption tables (namely Typical and maximum current consumption in Run mode, code with data processing running from Flash memory (ART accelerator disabled), regulator ON, All peripherals disabled) start at 25MHz, the extrapolated typ. value falls quite well between 7mA and 10mA.

What surprised me (and probably you too, as you've mentioned it) is Range3 VOS/1.12V on VCAPs as that is not the reset value; and the fact that FLASH content influences the consumption quite dramatically (if I may ask you to experiment, try writing only the first two words in FLASH to see whether that does produce most of the impact of nonempty FLASH, or not).

That current consumption during reset is not a DS parameter is sad, but note, that survival instinct pushes semiconductor manufacturers to list as little parameters in the DS as viable (these parameters are guaranteed and have serious $$$ consequences).

JW

[harerod]

...
What surprised me (and probably you too, as you've mentioned it) is Range3 VOS/1.12V on VCAPs as that is not the reset value; and the fact that FLASH content influences the consumption quite dramatically (if I may ask you to experiment, try writing only the first two words in FLASH to see whether that does produce most of the impact of nonempty FLASH, or not).
...

Isn't the CPU just a state machine that interprets the contents of the FLASH?
The beginning of the flash is a bit special, though. For STM32 this holds parameters for NVIC. The first addresses being SP and PC. On erased FLASH, those are both invalid and will trigger error handling. Next thing, I would expect the CPU either jogging and jumping through the memory, or maybe entering a stop mode.
If you want to experiment - try to hook up a debugger. Then see how the debugger interprets the FLASH contents. Then leave reset and single step the core. Should be fun to watch.

references:
PM0214 <- ST Manual for STM32F4x7
Cortex-M4 Revision r0p0 Technical Reference Manual <- ARM for M4
ARMv7-M Architecture Reference Manual <- opcode binaries listing (among other things)

[brumbarchris]

Thank you everyone for your replies, this thread sort of clarified it for me.

BR,
Cristian