Sleep current 2.5 times higher on STM32L072 after internal bootloader used

[LurkingKiwi]

Our product is battery powered and uses an STM32L072CZT6.

I did not write any of the power management code and I am not sure exactly what modes are used.

When cold started and left to go into power saving mode, the current drawn by the entire product averages 82uA.

However, after changing BOOT0, resetting, flashing the app using STM32CubeProgrammer, changing BOOT0 back, resetting again and letting the unit run until power-saving mode engages it then has an average current draw of 200uA, a 150% increase. I also discovered that re-flashing is not required; simply running the bootloader for a few seconds is enough to cause the problem, so it's not due to any code downloaded by the programmer.

There seems very little in the CPU which survives an external reset. The RCC registers look the same in each case, and the only difference in RTC registers is the change of time and next scheduled alarm.

Our console serial port is on PA2/3, there was a BlueTooth module on PA11/12 but that has been removed for testing.

PA9/10 have 4k7 external pull-ups. GPIOA registers readback all the same in each case.

Can anybody suggest any paths for investigation?

What does the bootloader configure which would survive a hard reset?
Are any pins other than PA2/3/9-12 configured which could cause other circuitry to be affected?

[waclawek.jan]

Do you use any of the analog features (ADC, DAC, COMP)?

I'd look at the FLASH, PWR and SYSCFG registers, too.

JW

[LurkingKiwi]

Unfortunately all the registers listed above are the same in both scenarios.

[Bubbles]

Hi @LurkingKiwi,

the Bootloader has the habit of reinitializing every GPIO it uses and then some more on top of that. It's also initializing every communication interface in the same way (SPI, UART, I2C, whatever is supported, se AN2606 for complete list)

Warm reset (without removing power supply) will not change the settings of all the GPIO. That's because some customers actually want the GPIOs to remain stable.

Happy hunting.

J

[LurkingKiwi]

As far as I can see in the manual, all the GPIO on an STM32L072 is cleared under reset.

I have just re-run the register captures and the GPIO reads are the same in each scenario.

I have also disconnected a CPU-controlled boost regulator to remove it as a source of bad behaviour.

AN2606 says the L072 bootloader only initialises 2 UARTs and USB, and I've checked all those registers.

Sorry, it looks like I forgot to click on Reply last month.

[waclawek.jan]

While the bootloader's sources are not publicly available, you can debug it in its disassembled form. In that way, you in theory can reconstruct all the changes to all registers the bootloader does, incorporate that into your program and observe, whether some of those writes increase the consumption. Or just try to single-step or place breakpoints into the bootloader, to find out at which point the consumption increases. I'm not sure what the debug functions you have at hand allow to do.

I know it's a long and painful journey with possibly no payoff.

JW

PS. Btw., are you sure the increased current goes entirely into the mcu? Couldn't some of the other circuits on your board "got awakened" by going through the bootloader, e.g. by some of the pins being pulled up/down by the bootloader?

[LurkingKiwi]

The only thing left in the test product that is not simply a resistive (or LED) load or input is the cellular modem.

However, I believe that initialising the modem and connecting to the internet, then shutting it down exercises all the connections between the two and should(TM) clear any random inputs. There could plausibly be latch-up issues with pins defined as pull-down only with internal pull-ups to voltages < 3V being driven to 3V5 rather than an OD output.

I do have a module with a faulty modem, and will get a tech to remove the modem at some point so I can definitely isolate that. It's fairly low priority I'm afraid.