Arduino for STM32

Using the built in sleep library "STM32LowPower.h"

When going into deep sleep mode, I'm still reading around 4-5mA, from what I've been told we should be able to get this number down into the uA.

Is there anything more I can do to reduce this number?

I did see https://electronics.stackexchange.com/q ... -stop-mode
Where would this flag to turn off low power debug mode, within the various configs and headers for stm32duino?
If anyone could let me know that would be really great... and is some what urgent

Thanks

030RC ! quite a 'big' chip, for a small uP.
a usual thing is check connected peripherals, e.g. led (1ma-20ma) - but that'd be too obvious
less obvious stuff may be the LDO, and 'other' peripherals that perhaps sink currents even if it is 'doing nothing'
then in extreme cases unclock various on chip buses etc. those could possibly save some power

I thought the F0 range was meant to be for low power? Or did I have that wrong?
Yeah the LDO battery chip is going and hopefully we should see some significant improvements there. But I feel we should still be able to reduce the stm32 further than 4mA

STM32L is for low power ...
Link to your board?
Is external hardware (sensors, display etc) connected?

for what is worth, I've got a stm32f103c8 'blue pill' whose VBAT (that is supposed to take microamps), drain a CR2032 in like a few weeks.
then that after the 'tests' I use a different board with a stm32f103c8, this time round a single lithium coin cell CR2032 keeps RTC running for practically over a year. there can be variances between same chip skus.

To 'proof' if it is after all the stm32 itself consuming power, one way is to unclock the peripherals. or perhaps use a core in which all the pheriperials (spi, i2c, uart, adc, etc) including gpio are not initialized, no hal nothing and just systick and only the cpu running. if you go to 'deep sleep' on that firmware and there is a difference in current consumption vs leaving the peripherals clocked. That would point to that keeping the peripherals (including gpio) clocked possibly consume power there. But this is 'hard core' and it'd take being able to measure those small currents to check that.

quite often I find that tedious, and decide mostly to simply turn that off (i.e. physical switch) and keeping only RTC on VBAT. or that I run off 'generous' power supply such as keeping it connected to power supply (e.g. a usb charger) or a mobile power bank.

I'd normally 'ignore' the notions of 'low power' chips as I think normal stm32 commonly consume little power on their own. And that 'low power' actually requires use of 'special' (low power) peripherals and more measures to achieve that. using 'ordinary' stm32 within its constraints is more convenient vs trying to do those 'specialized' low power means.

See viewtopic.php?p=14053#p14053

fpiSTM wrote: Wed May 29, 2024 7:29 am See viewtopic.php?p=14053#p14053

Thanks will look into... Might be able to test tomorrow...

Hi all a bit of a bump as ive been testing out new prototype.
Sadly though even with the new HAL clock disable code, I'm still reading about 4mA when in deep sleep.
I still need to test after setting unused pins to analog input but, this isnt promising news...
Is there anything else I can do to get this into a deeper deeper sleep? Or is this the limitation point of this chip?

1. There is no deep sleep for STM32-MCUs.
Low Power modes are: sleep, stop, standby - read the datasheet and use correct terms.

2. No one knows what kind of board you made, which way you clock the MCU etc.

3. In table 25 I see:

STM32ardui wrote: Tue Jul 30, 2024 5:00 am 1. There is no deep sleep for STM32-MCUs.
Low Power modes are: sleep, stop, standby - read the datasheet and use correct terms.

2. No one knows what kind of board you made, which way you clock the MCU etc.

3. In table 25 I see:

Code: Select all

Supply current in Sleep mode, code
executing from Flash or RAM
HSI or HSE clock, PLL on  48 MHz IDD = 14 mA
HSI or HSE clock, PLL off  8 MHz IDD = 2,6 mA

Deepsleep is a feature in the Low Power library bundled with stm32.