Anything lower power than STM32L4? - Page 1
Forum section: electronics / general

author: hans
author_rank: Super Contributor
timestamp: July 15, 2023, 07:16:54 am
content: I've made a prototype with a STM32L431 for a low power project. It continuously samples the ADC at 8ks/s, does some DSP stuff, and then spits out data over a digital interface of choice. I antipicated I would use the Cortex-m4 FPU or SIMD instructions, but ultimately I did not. Power consumption is a big factor in this project, so I'm running the MCU at only 400kHz to keep the power low. It's an always-on project so I can't exactly burst the clock speed.I've been looking for potentially alternative MCUs as I find the power consumption still a bit high; ~100uW at 1.8V, and I want to see how low I can get it (it's an academic project). As I said, the algorithm is fairly simple and operates mostly on 16-bit (signed) integers, so I perhaps don't even need a 32-bit MCU. But I've a hard time finding a suitable replacement. Most MCUs I've looked at hide their "real" consumption behind DC/DCs powered from 3V or by runnning pointless while(1) programs. When marketing is stripped away, most MCus are still 45-80uA/MHz, while many of them scale horribly down to <=1MHz (e.g. Silabs has many interesting MCUs, but report 150-200uA @ 1MHz).Now perhaps I will need to do my own characterization since I'm targetting a few hunderd kHz (e.g. use ext osc like SiT1569). But does anyone know of a MCU that can get close to STM32L4s efficiency? It's been almost 5 years since I've settled on that part, so I'm hoping that something better was released meanwhile..If needed, I can do with an external 12-bit ADC (ADS7042) over SPI. I've calculated it should consume around 15uW at 8ksps, which would make it slightly more efficient than ST's internal ADC on the L4 chip.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 15, 2023, 08:12:00 am
content: 100uw at 1.8V is 55uA, with peripherals, CPU, everything running, will be hard to beat.SAM L0/L1 offer 25uA/MHz, it's less than half than ST's.Furthermore wake up time is 1.5uS, so you should be able to sleep the mcu between ADC conversions, the stm32 could do this too.Mormally it's more efficient to run the mcu fast, do the job and sleep most of the time, using a low power timer to wake the mcu.

author: peter-h
author_rank: Super Contributor
timestamp: July 15, 2023, 09:39:39 am
content: QuoteI've done exactly that in a number of products, with the great advantage that you don't need a "low power CPU"Can anyone summarise what an L43x does over a non-L one?Every CMOS CPU draws less power at a lower clock. Maybe the non-L can't run that slow?Looking at the (e.g.) STM32L471xx DS I see the RTC draws 300nA which is excellent - equal to the best RTC chip ever: the 30+ year old DS1302. STM32L431 is 200nA!Ah, 80MHz max. So that's the price paid.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 15, 2023, 10:42:57 am
content: Quote from: peter-h on July 15, 2023, 09:39:39 amIndeed that's the right way to do it, and "low power MCU" actually is not just something with low mW/MHz, but something which has useful hardware features to enable sleeping the thing. For example, ADC which can DMA into RAM while all other peripherals and the CPU core are powered off.Because the elephant in the room is, how often you need to wake up? Especially if you need accurate crystal, waking up an XTAL takes tens-hundreds of µs. Not a problem to do once a second, but clearly a problem at 10kHz. Now the two ways to deal with this are, wake up quicker so you can wake up more often without much overhead (CPU running on RC oscillator designed for this does not take even a microsecond); or design the MCU such that you don't need to wake up that often, i.e., more autonomous hardware which can do sensible things from software initialization/configuration alone. And of course, multiple clock sources for different needs, because some are lower power than the others.My experience with nRF52 for example is they have done this quite right. You can use a dedicated 32768Hz clock crystal based timer, which only consumes a few µA, to trigger any peripheral to do basically anything. Power is managed automagically so that when a peripheral is triggered to do something, only then the power is enabled to it. RAM can be enabled/disabled in blocks to further save some µA while keeping part of RAM functional, and have retention-only vs. use modes.Running the whole chip from a slower clock is really old-school way and far from optimum. Static power consumption of the chip alone is a real problem, linear scaling mA/MHz has an offset in it.

author: hans
author_rank: Super Contributor
timestamp: July 15, 2023, 10:45:18 am
content: Quote from: peter-h on July 15, 2023, 09:39:39 amLogic is synthesized for a PDK that is optimized for low power. Those PDKs have higher propagation delays but lower power consumption.Some MCUs feature on-chip DC/DCs to power Vcore or VDD. Unfortunately, reports are still in uA/MHz, which is relevant for LDOs, but in DC/DC I would rather see uW/MHz. In my case I'm already powering the MCU from 1.8V, which is generally around the lower bound for many MCUs.And then there are a few bits and pieces with regards the MCU design. Some MCUs allow for clock requests while the part is in standby, which briefly boots the clock for a peripheral to do it's job and then go back to standby. The STM32L4 doesn't support this, but the U5 series does. Some MCUs can do DMA transactions etc. "in standby". But in my case, the application has an I/O-limitation, which hooks into :Quote from: DavidAlfa on July 15, 2023, 08:12:00 amYes, normally race to sleep is king for the best computational efficiency points. But I'm concentrating on the active power consumption of my design, as that's what I would have to report in a paper when it comes to thatThe design in question is a prototype RF modem on some novel modulation technique I'm experimenting with. The intent is to have a battery-free system. Depending on the amount of energy harvesting available the MCU will still need to be duty cycled.. but purely concentrating on the RF receive function (This question), that is still completely I/O limited by the ADC.I could probably also implement all the radio functions for FPGA/ASIC, as we do have ASIC synthesis tools on our university, but I fear that's another huge rabbit hole to step into. I've seen some papers using FPGAs before despite its high static power (ICE40UP5K draws around 75uA statically), and one can argue about whether its fair to leave out the FPGA static power and only include active power consumption of such a design. Personally I think it is rather rhetorical representation, because at this power scale everything matters, including oscillators and I/O power. The ADS7042 ADC I mentioned consumes 7uW @ 10ksps. But driving 2 "HiZ" pins at 160kHz with several dozen pF of capacitance yields 5-10uW power consumption (calculation). In other words, the SPI bus to the ADC will probably consume more than the ADC itself.Early this week I've tried to do an arrangement like you said. LSI at 32kHz or so, LPTIM1 was physically looped back into a HF timer that created wake pulses at 8kHz from STOP1 or STOP2 (1-4uA sleep consumption). In that experiment I rigged it for an external ADC, so I made the LPTIM1 output a pulse with 25% duty cycle so it could be reused as a chip-select line for the aforementioned ADS7042 ADC. I could not get the SPI transaction initiated correctly using DMA from the HF timer (I presume because the part is still sleeping), so I did it in the timer IRQ instead. I did use DMA for SPI Rx to put it into the circular buffer. Unfortunately, the average power consumption was horrendous at 300-330uW. I figured this is because the STOP1 or STOP2 => RUN transition with MSI=4MHz takes 12us but has a current spike of 1.5mA or so. 12us*1.5mA*8000Hz*1.8V=259uW.I then found this appnote that basically reiterates on this:https://www.st.com/resource/en/application_note/an4746-optimizing-power-and-performance-with-stm32l4-and-stm32l4-series-microcontrollers-stmicroelectronics.pdf(page 13)I've seen the ATSAML10 part I think you are referring to. But its 25uA/MHz report is unfortunately polished in two ways; it's from a DC/DC@3.3V, and it's for running a while(1) program. At 4MHz 1.8V LDO in Coremark, it manages 78uA/MHz, which is a bit lower than the STM32L4 (211uA @ 2MHz, 460uA @ 4MHz).It looks like an interesting candidate to try out, and see if it is more efficient.

author: hans
author_rank: Super Contributor
timestamp: July 15, 2023, 11:03:28 am
content: I already wrote the previous post, didn't want to rewrite it again:Quote from: Siwastaja on July 15, 2023, 10:42:57 amYes it is old-school, but that is because I figured that if MCU with clock-demand is going to boot its HFCLK at 8kHz it will struggle in similar ways (akin to the experiment with LPTIM I described in my last post). The STM32L4 MSI clock @ 2-4MHz is reasonably quick, several microseconds to start up.Doing background I/O with a 32kHz clock sounds much better, but then it would be the question whether the bus etc. can keep up with e.g. 8k DMA transactions/second at just a 32kHz clock. In the STM32L4 test with the LPTIM, I saw considerable jitter on the SPI transactions, where it would almost go outside the static CS window from the hardware timer. I traced it down to the point when the CPU was running the radio demodulation code. And that is with several MHz bus speed. DMA was running at highest priority.The CPU only needs to wake up at 125Hz, as the demod code runs every 64 ADC samples. The algorithm I use locks itself onto the async datastream (since its derived from RF), and that lock has to remain OK during the remainder of the packet. That means it can tolerate static offsets, but it won't tolerate high jitter or gross freq inaccuracies very well.I've heard good stories from Nordic chipsets. We had a talk from them a few months ago. Our first question was whether we could get access to the I/Q data from their on-chip modems, but that seemed hard as it was handled by a closed-source coprocessor. In my application, it would also be rather confusing to use a MCU with onboard radio, unfortunately, as it needs to be very clear(&convincing) that all RF(ID-like) communications is done with passive/discrete components that consume uW's.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 15, 2023, 11:06:51 am
content: Quote from: Siwastaja on July 15, 2023, 10:42:57 amOr run on the RC osc ( assuming it has good short-term stability) and do occasional calibrations against the Xtal.

author: peter-h
author_rank: Super Contributor
timestamp: July 15, 2023, 11:11:31 am
content: Pity one can't just run the 32k oscillator and upconvert with the PLL to 168MHz when you come out of sleep. Or just be generating the 168MHz all the time but not feed it anywhere.Even the 32F4 can turn clocks on/off to various peripherals, for some limited benefit.One tries to avoid 1-2MHz crystals due to various problems, although ceramic resonators are fine.

author: nctnico
author_rank: Super Contributor
timestamp: July 15, 2023, 11:13:30 am
content: Did you look at TI? Last time I needed something really low power, I used the MSP430 series. The MSP430 series has been designed from the ground to be ultra low power so chances are very high you find something more suitable compared an ARM core that is shoehorned into something it wasn't designed for.At 8ks/s you might still get a benefit from putting the processor to sleep between samples. What is often not in the headline specs is the time needed to switch between sleep and running modes. For applications that need to wakeup often, this can make a huge difference. Several years ago I designed a gadget around an MSP430. I didn't really try hard to make it low power from the software side but it beat an ulta-low power PIC implementation with hand crafted assembly by a factor 3 where it came to power consumption.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: July 15, 2023, 11:14:18 am
content: Quote from: peter-h on July 15, 2023, 11:11:31 amI'd imagine PLLing a low-power 32K xtal up to 168MHz could be rather jittery

author: eutectique
author_rank: Frequent Contributor
timestamp: July 15, 2023, 12:55:53 pm
content: I would suggest to look at Apollo SOCs fromAmbiq. They are designed for power-limited applications.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 15, 2023, 01:57:09 pm
content: Quote from: mikeselectricstuff on July 15, 2023, 11:14:18 amThe PLL normally needs 4-8MHz input, also won't multiply by 5000!

author: coppice
author_rank: Super Contributor
timestamp: July 15, 2023, 05:38:37 pm
content: Quote from: DavidAlfa on July 15, 2023, 08:12:00 amThe MSP430 family was way ahead of its competition in these types of application for years, because it took so long for the competition to properly embrace this simple reality.Make sure the core can wake and and go back to sleep really fast. Make sure there is a super low consumption modest speed clock. Make sure the fast core clock is effectively gated. Make sure each peripheral's design allows it to only consume for the minimum possible amount of time. Its no use slowing down the core clock, and leaving something like an ADC consuming 100% of the time. Get things over with fast, and get to sleep.

author: wek
author_rank: Frequent Contributor
timestamp: July 15, 2023, 06:36:24 pm
content: This companyis touting their subthreshold-CMOS technology and the Apollo Cortex-M mcus based on that technology, as the best thing in low-power since sliced bread.I have no experience (nor affiliation of course) but maybe academic setting is ideal to test these things...... and I'm trying to sell this idea so that somebody else tests these things and let me (us) know whether they're worth... ;-)JW

author: coppice
author_rank: Super Contributor
timestamp: July 15, 2023, 07:06:23 pm
content: Quote from: wek on July 15, 2023, 06:36:24 pmI've been seeing the name Ambiq for years, but the only time I saw it in connection with a real world application was something about Xiaomi using them in a smart watch. I find that interesting, as I assumed they were going to be expensive parts, but Xiaomi is very much focussed on value for money products.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 15, 2023, 08:13:05 pm
content: You can use a switching regulator for the Vcore of some MCUs of the L4 series, did you?Should get you down to about 30-35µA/MHz. If you are not doing this, I strongly suggest having a look at this option.Otherwise, that's the ballpark of the common ARM-based ultra-low power MCUs out there. Something from 30µA/MHz to 100µA/MHz.Lower than this with a Cortex-M4, the only ones I know (and which I've talked about before) are the Ambiq MCUs (Apollo 2, 3, 4). *These* are absolutely impossible to beat right now with anything else off-the-shelf.https://ambiq.com/products/

author: hans
author_rank: Super Contributor
timestamp: July 17, 2023, 07:52:03 am
content: Quote from: nctnico on July 15, 2023, 11:13:30 amYes I did. Most cores I found do around 100uA/MHz scale, with their own linear fits in datasheets also naming a 50-60uA offset.I think they were innovators when it came to low power stuff, but in my view they have some niches at best (FRAM)Quote from: eutectique on July 15, 2023, 12:55:53 pmOh these look quite interesting. I will have a look. I think I remember seeing these chips a long time ago. If those figures are real and they scale down well, then this is the chip to use.The 0.5mm BGA package isn't that inviting to me (no reflow oven). But I'm willing to give it a try with hot air.Quote from: coppice on July 15, 2023, 05:38:37 pmI've been thinking about the post from Siwastaja, and I think my application still will have some difficulties mapping that onto real hardware.I would love to use e.g. a 32k crystal (which can be always-on) to have it run this ADC I/O task, but I think the sample rate is just too high. A 12-bit SAR ADC typically needs 6-12 clocks to perform a conversion. Thus 32kHz isn't fast enough.I could use the 32k crystal to pace things accurately and then have a high-speed clock deal with the actual conversion task, however, if those high-speed clocks have high current peaks at start-up that basically requires them to be constant-on as well.Quote from: wek on July 15, 2023, 06:36:24 pmAgreed. I've no pressure on having to deliver a box of products that "just works" in say xx months.It's also an ideal place to go out of my way to do things differently, just to see if it would work.Quote from: SiliconWizard on July 15, 2023, 08:13:05 pmNo I've not. I think I've dismissed that route too early, as the STM32L433 does have a DC/DC version that is worth atleast swapping out for. Thanks!

author: Berni
author_rank: Super Contributor
timestamp: July 17, 2023, 09:35:03 am
content: Yep a STM32L4 is very good at being low power.Yes there are lots of tiny 8bit MCUs out there that will do even lower power, but the raw computational performance of those ancient low transistor count CPUs is not great.I am using a STM32L4 as a background processor in a product and have resorted to just simply running the MCU at 100KHz from internal RC during the products standby mode as that already made it consume under 100uA (including all the 12V power regulation and other stuff on the board), so i don't even make use of sleep mode. It just runs in the background and waits for power on events from various sources.Tho actually reaching the datasheet numbers for these chips takes a fair bit of care. It is important to stop any oscillators you ware not using, power down unused peripherals. This includes even disabling GPIO pins that are not used! If a digital input buffer inside the IO pin sees a in between voltage that is a proper 0 or 1 this can bring it in a confused metastable state where it pulls 10s or even 100s of uA from the power supply, with high pin count chips this can add up a lot. You can also save even more power by shutting down flash memory and running from RAM only. As for what the CPU is doing matters very little in these simple chips, doing a while(1) or actually doing math consumes a nearly identical amount of power. Sometimes while(1) can actually consume more power because some more complex algorithms can overwhelm caches, causing the CPU to stall and wait for data.For SIMD yeah they are not that useful on small ARM MCUs since they can usually only work with 32bits at a time. So only a big boost if you need a lot of 8bit math. But float support is powerful on them. When doing FFT i found that the official ARMs FFT library runs a fair bit faster in floating point mode. The single float or 32bit fixed point multiply both take just 1 cycle to execute. But using float frees up more CPU registers for the compiler to use (since float has its own registers) and sometimes simplifies algorithms (shifting up/down, overflow checks, edge cases, etc..)Also as people said DMA is a huge help with low power. It means you can go to sleep and still collect ADC samples, or even if you don't use sleep then you can use the CPU cycles to do useful computation rather than spoon feeding the ADC or spending a lot of cycles doing context saving due to ISR routine entry and exits.

author: hans
author_rank: Super Contributor
timestamp: July 17, 2023, 06:56:40 pm
content: I've taken a look at the Ambiq Micro processors today.First Apollo 2. Unfortunately it's ADC consume quite a lot of power. 17 uA for 10Hz conversions. So I would need to use an external ADC.I find the current consumption w.r.t power saving modes and the individual components to be somewhat lacking. The part consumes ~700uA @ 3.3V and 48MHz. That's very good. STM32L412-P needs 1550uA. The part drops down to 105uA during "WFI". STM32L412-P needs 360uA. That's the end of the good start, though.The rest of the part (&doc) seems very sparse. It features some basic SPI/I2C/I2S and timers, but that's about it. No HF clk input (only output for dbg I presume), so accurate timing must be done on 32.768kHz or via the oscillator calibration. And to my biggest surprise: no DMA! The SPI modules instead has a 128-byte FIFO and some kind of "command" system.The "Apollo" chip (their first MCU) has similar featureset, but with a 24MHz Cortex-m4 (which would be fine), slightly higher run currents (840uA @ 3.3V for 24MHz), but with 57uA in "WFI". That suggests the majority of that power in WFI goes into HFRC, which.. cannot be shutdown & fed externally as it doesn't support a clk input.That means that the MCU always runs 48MHz, and if it's waiting on I/O it's just wasting power. The wake-up time is around 24.5us with buck regulator. If I presume that 1 SPI transaction takes say 60 cycles to complete (IRQ entry+16 SPI bits @ 24MHz+ADC buffer store+exit), then the total run time is around 26us per ADC sample, or 208ms/s run-time for doing 8ks/s of ADC transactions.The timer can be clocked by the LFRC(1k RC int osc) or XT(32.768kHz crystal), so atleast that is flexible. But I fear the average power consumption: Assuming zero current spike during deepsleep=>run transition, the average current consumption would be roughly:(1-0.208)*3.2uA + 0.208*14.5uA/MHz*48MHz=147.3uA.So I then took a look Apollo3. This chip does feature DMA, which is run from APB_CLK (HF, 48MHz).The rest of the part seems very similar; same 48MHz HFRC. It has an option to use 'high performance mode' for 96MHz, but with worse uA/MHz. The core itself is slightly more efficient at 10.3uA/MHz, and now only 63uA "WFI" current. Repeat:(1-0.208)*2.3uA + 0.208*10.3uA/MHz*48MHz=104.7uA.Still not terrific..Their way of structuring the DMA into peripherals feels a bit upside down, as the DMA registers are configured inside the peripheral. However, a search for "circular" yields 0 results. So does that mean that streaming data from e.g. SPI or ADC to memory needs to be restarted each time the buffer was filled?The 32MHz crystal needed for the Bluetooth radio seems to be independent of the rest of the system..Apollo4 is the biggest part, but it seems a misfit to my project. Everything is too big: 192MHz MCU, worse efficiency than Apollo3, MB's of RAM.. 330uW "WFI" mode, lowest current draw is 7.2uA @ 3.3V, all oscillators off, all RAM blocks off and DC/DC (!). So it takes 24uW doing "nothing".Scrolling through the datasheets seems that these parts have their unique use-cases (strongest of which: low power CPU), but not for this project. I also found idiocracies in the datasheet IMO, such confusing terminology used (e.g. describing DMA as a means to transfer data "withoutMCUintervention" -- you mean CPU?), figures and diagrams that need more JPEG and therefore are hard to read, and reference manuals locked behind a login portal. Its noticeable they are a new company where they need to settle in ways to doing things.I wouldn't say e.g. ST is perfect neither. In my opinion they have a tendency to give 50% of the details at 1 spot and then have you scroll its 3000 page reference manual.I also took a look at STM32L412-P part today. It seems to be compatible with the L433-P and 2 other devices, which both come with more memory and peripherals, but also a bigger power bill.But.. the DC/DC addition seems to only work for "Range1/2" run operations. In LPRun, which can work up 2MHz, a low-power regulator is used which has a lower quiescent current. Since the -P parts shutdown the internal regulators and depend on an external SMPS to feed VCore, this differentiation is not present. VCore needs to be 1.0V for up to 26MHz operation. The power "savings" for these lower frequencies is thereby not as substantial.. but it's still nice to have.E.g. it can do 2MHz @ 100uA 3.3V 85% (50uA/MHz), whereas without DC/DC it's around 200uA. The savings are more substantial are higher frequencies though.So far it looks like the STM32L412-P is still the best candidate, also given that I can reuse most of my BSP code. The ATSAML10 was also mentioned here, but it also has 50uA/MHz efficiency at 4MHz, so there is not much to gain compared to L412-P except maybe the on-demand peripheral clock requests.

author: nctnico
author_rank: Super Contributor
timestamp: July 17, 2023, 07:11:40 pm
content: Quote from: hans on July 17, 2023, 07:52:03 amIMHO you are still on the wrong path here by trying to find a microcontroller that has the lowest power consumption while running continuously. With 8ks/s you are looking at a 125us interval. AFAIK the MSP430 can wakeup in 1us to name an example. Say your code needs 20us to run, you can sleep for 100us slashing the consumption to 1/5th of the spec you are looking at. The MSP430 project I mentioned earlier needed a few uA (less than 5) to run. And as other suggested: if you let the ADC run from a timer + DMA, you can leave the CPU sleeping for even longer times and thus reducing power consumption even further. My estimation is that you should be able to get your project into the 10uA or less ballpark IF you put the CPU in sleep mode between samples.

author: hans
author_rank: Super Contributor
timestamp: July 17, 2023, 08:29:41 pm
content: Perhaps I'm not on the same wavelength, but I don't think it's possible for 8ks/s.I've opened a few datasheets of the MSP430, but maybe I'm not looking at the right part (MSP430 is a complete series after all).This seems to be typical, 5-7us wakeup:E.g.https://www.ti.com/lit/ds/symlink/msp430fr69891.pdfSo I could have the 8ksps run from 32.768kHz in LPM3 (0.4uA), and then have DMA switch make the part go briefly into active mode to allow ADC to convert (section 6.3.1, footnote 4)Table 5-10. Typical Wake-up Charge LPM3 to active mode: 16.5nAs16.5nAs*2.2V=36.3nJ, or 290uW.Figure 5.13.4.1 even plots it.This data looks very similar to the results I've gotten with the STM32L4 and "manual" wake-ups from standby. The data also looks similar to the appnote from ST I linked in.

author: tszaboo
author_rank: Super Contributor
timestamp: July 17, 2023, 09:17:29 pm
content: If you need frequent wakeups, then you shouldn't go to deep sleep modes. For example your STM43L4 will wake up within a few CPU cycles from regular sleep, the same us most ARM micros.Also, do you need instant response for your ADC results? Can't you DMA it into the memory and process it in a batch?Also you made me look at the STM32U5 now. Hot damn, it's running a from 1mA at 24MHz in some conditions.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 17, 2023, 09:47:54 pm
content: Quote from: hans on July 17, 2023, 07:52:03 amRC oscillators can start quite quickly. LDOs sometimes also need to change modes, which adds more lost-time.If you are close with 32Khz but need a little more speed for important frequent tasks, you can get uA oscillators like SIT1569, above 32.768kHz and up to 462.5kHzNo Load Supply Current IDD1.7 < 3 μA FOUT = 1 Hz3.3 < 4.6μA FOUT = 100 kHz8 < 10μA FOUT = 462.5 kHzI would still expect FLASH reading to be an offset-origin problem, ie slower clocks will actually be worse, energy wise, than burst and sleep (no flash).

author: Berni
author_rank: Super Contributor
timestamp: July 18, 2023, 07:32:01 am
content: Sounds like that STM32U5 family is indeed just the right thing for this kind of project where you need to still do stuff in sleep mode.Even the old STM32L4 series can do impressively low consumption when running underclocked from internal RC. It runs from flash at 8MHz using 1mA of power, or does only 30uA when running from flash at 100 KHz (all peripherals off of course).The problem that the L4 series has is that putting the CPU into sleep mode still consumes a lot of power at low speeds. Like 100KHz sleep is 15uA. While power modes lower than that kill the CPU to the extent that waking up becomes a fair bit more work. This is where that STM32U5 shines. It appears you can set that one up to DMA from the ADC to RAM and while completely killing the CPU. That way you can have ADC doing it's thing and only wake up the CPU once per second, running it at a few MHz to process the data quickly and get back to sleep.

author: wek
author_rank: Frequent Contributor
timestamp: July 18, 2023, 09:23:10 am
content: Quote from: hans on July 17, 2023, 06:56:40 pmThanks for the overview.QuoteAnd it scales with sampling rate? I couldn't find data, but that wouldn't sound right.All in all it appears that unless they fit a particular purpose they are not worth the hassle.Looking forward to your real-world findings :-)JW

author: hans
author_rank: Super Contributor
timestamp: July 18, 2023, 10:16:24 am
content: Yes, the hardware handling everything during sleep would be ideal.But at 8ks/s or 8000 system "wakeups" per second (not the CPU, but the HF OSC subsystem needs to run briefly), I think it's all about which MCU can do that (VREG/OSC startup) with the least amount of power.OR as PCB.wiz suggests, run a background oscillator at a few hundred kHz for <10uA. But the problem I foresee with that, is that e.g. STM32L4/L0 don't do wakeups on external oscillators, only HSI or MSI. Haven't looked at other MCUs; but not sure. So to use ext OSC is a multi-step process to boot, so that makes the background oscillator not being used.From a reliability point of view, booting from ext OSC sounds horrible, and for crystals would consume a lot of power. Maybe an oscillator is better. But either way, both could fail and that would lock up the system (unless there is a clock WDG running from the 32kHz crystal).I happen to have a STM32U575 nucleo on hand and a EFM32PG12 board which I ordered for the project 3 years ago (have I said time runs a lot slower in academia?). I found the EFM32PG12 interesting because its HFRC can boot up in supposedly 300ns at 19MHz. It doesn't specify any current spikes though, but I'm keen to find out. Wake-up to SRAM is only 3-4us also, very quick, but if the PRS & LDMA can do everything during EM2, then I would only need CPU wakeups at a few dozen Hz.Now the U575 also looks interesting. The 16nAs "wakeup" I posted yesterday from MSP430 looks ridiculously high. The U575 suppodesly does 0.8nAs with MSI 24MHz clock and LDO, and 0.2nAs on DC/DC HSI16MHz (I sure hope that is not a typo).It's unfortunate that I don't have ""a"" MSP430 board on hand (I do have a Launchpad but its ancient, that MCU can wakeup in 1.5us as @nctnico said BTW), because it would be most fair to test all of them. Unfortunately filtering parts for their latest gen devices on TI's website is absolutely horrible. No idea where to start, and I don't look forward to opening dozens of datasheets to find the details I need.I'll keep you guys posted when I've finished some tests on the STM32U575 and EFM32PG12 boards.

author: hans
author_rank: Super Contributor
timestamp: July 20, 2023, 09:48:43 pm
content: WIP postI've tried both MCUs past few days. First some general remarks. Skip the next 2 paragraphs if you just want to know the results.I like the EFM32 series a lot. The whole part is orientated to low power: all peripherals indicate the lowest energy mode they operate at. The PRS integrates event triggers in/out of peripherals and links them together, to/from GPIO and to/from DMA. It also has some basic logic gate functions and edge detections. Many digital GPIOs have many alternate locations, some even 32 alternate locations! E.g. it has a SPI bus on all 8 lower pins of a port, so its easy to pin swap things around. I found the chip features powerful yet amazingly simple to use. The low power tests I wanted to do didn't take more than a couple of hours. I don't like their IDE though. It feels like eclipse was given too little heap, and so runs laggy (I honestly typed all my code in VS Code, it was that appalling). And although their starter kits comes with a nice power profiler, its tedious to constantly switch between upload/debug and the power profiler. It errors while the debug session is running, takes 15 secs to switch, etc. You can upload HEX files in the profiler, but for some reason the MCUs wouldn't enter their standby modes with them. So the experiment part was the tedious bit.I (and many others I'm sure) am familiar with ST's chips. I honestly don't mind STM32CubeIDE as much. The STM32U5 chip has everything including the kitchen sink. And TBH it doesn't feel that much of a low-power chip as SiLabs desgns; many peripherals are not intended for clock-less operation, and honestly it feels like a H7 design on a power-diet and some extra attention given to APB3/AHB3 with its own LPDMA + low-power timer/1 SPI port/UARTs to do sleepy designs.My biggest rant is their documentation though. I had set up the LPTIM1 as a timebase, mapped the compare output to a GPIO to make sure it kept working. Enter any STOP mode: PWM is gone. Search online on their forums: ST employee says you need to enable "LPBAM" (Low-Power Batch Autonomous Mode) for it to work in STOP modes. CTRL+F "LPBAM" on their 3000 page reference manual: 8 results, mostly in introduction sections of chapters. None of them mention anything w.r.t their HAL code or RTL bits. I found it much more straightforward to skip their HAL and RM documentation, and go straight into all of the 52 RCC registers, and backtrack anything I don't what it does. After a few hours of head-bashing I found it need to enable the SmartRun features, e.g. the SRD bits in RCC, which is separate from the clock enable in STOP mode configurations.[/end of rant]The nucleo has no power profiler, so I used a Nordic PPK2.Regarding the attachments:The EFM32PG12 internal ADC isn't terrifically efficient. Almost 567uW @ 3.3V, with DC/DC, and 8.2ksps. The power does scale nicely down to 1Hz, showing that the oscillators shutdown very well.Unfortunately this part doesn't support its USART(used for SPI) down into EM2 mode. I did do a test in EM1, but its results are kinda pointless to show as the part consumes almost 600uW just running at its lowest clock speed.The STM32U575 is lower power with just under 120uW @ 1.8V, with DC/DC, and 8.2ksps. But it didn't scale well down to 1Hz. This is already after reducing its MSI oscillators to <1MHz, as at 4MHz the baseline was around 40uA. It suggests to me that the MSI does not shutdown, for some reason. Maybe a power bug still somewhere. I figured this, because LPTIM was clocked by LSE but would still stop working if I disabled its SRD enable and/or clock in STOP config.I also tested extra the power consumption caused by additioanl CPU wakeups. At 8.2ksps the CPU wakes up at 128Hz, which is 45-50uA on both parts. While that is not zero, I don't see it as the bottleneck for now. The DSP code also takes 200k cycles to run, so that also adds some offset.I think I will do some more tests on the ST chip to see if I can get SPI3 to operate in the low energy autonomous mode. And whether there is any bug in the MSI setup. It's frustrating though because I already ran through all the RCC+PWR registers several times already.I also have a ERF32MG22 chip used in another project that I may try tooling for this experiment. That chip does support SPI in clocks-off mode..

author: Berni
author_rank: Super Contributor
timestamp: July 21, 2023, 05:24:26 am
content: Yeah the documentation on STMs is not great... nor is that HAL library. But for me it is easier to stick with the devil i know.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: July 21, 2023, 12:30:55 pm
content: I did not read all posts completely but I do agree that going with a relatively fast clock combined with lots of sleeping is usually the way to go.Getting the most out of any very low power system also needs careful programming, but Hans seems quite familiar with this stuff.STM32 also has quite an elaborate clock system, Maybe a scheme with running the 32kHz oscillator continuously, combined with a fast RC clock, and then switching to a crystal only when more accurate timing is required is an option. I guess there are also application notes for periodic re-calibration of the RC oscillator for temperature changes and such.