<korken89[m]>
Hi all, I remember there was someone here that was testing lowpower stuff with RTIC and an L4 or L0, does it happen that someone has examples for this?
<firefrommoonligh>
LMK if you have non-RTIC-related low-power questions
<firefrommoonligh>
IIRC RTIC will auto put your device in sleep mode, but doesn't handle it beyond that
<firefrommoonligh>
Does RTIC handle low power modes beyond sleep? IIRC it puts your device in sleep mode when idle
<firefrommoonligh>
You'd need to enter low power modes beyond that in your #idle function or something
<dirbaio[m]>
rtic's idle is `loop { wfi }` by default
<firefrommoonligh>
So, as long as no interrupts are pending and cortex's deep sleep bit isn't set, it should go to sleep on most (all?) stm32s
<firefrommoonligh>
My gut says rephrase your search without RTIC, and enter low power modes normally, bearing in mind this auto-WFI.
<firefrommoonligh>
So, you could set the bits which specify the low power mode to enter, then RTIC's auto-wfi will initiate the mode, instead of calling it manually as you'd do otherwise
<firefrommoonligh>
For example, to enter stop mode, you'd set the `LPMS` bit as appropriate at the end of your idle fn, (For standby, also clear WUFx bits`, and at the top of your idle fn, re-init the PLL
<firefrommoonligh>
* For example, to enter stop mode, you'd set SLEEPDEEP in cortex-m, the `LPMS` bit as appropriate at the end of your idle fn, (For standby, also clear WUFx bits`, and at the top of your idle fn, re-init the PLL
<jamwaffles[m]>
korken89: I was doing some L0 stuff with RTIC, putting it to deep sleep on button press. That kind of thing?
<korken89[m]>
Yeah
<korken89[m]>
I'm looking at how to move between like 48 MHz MSI to 100khz and run low power run\
<korken89[m]>
* I'm looking at how to move between like 48 MHz MSI to 100khz and run low power run
<korken89[m]>
<firefrommoonligh "Does RTIC handle low power modes"> Indeed, the WFI is automatic - but the rest is on you
<firefrommoonligh>
Note that if you are only using sleep mode and don't mess with the SLEEPDEEP bit, it should be automatic based on korken89 's comment
<firefrommoonligh>
If you're doing it on button press, you'd need to tweak to use WFE instead of WFI; I'm not sure how RTIC handles that
<firefrommoonligh>
Sleep, stop, and standby work similar across STM32, but the L series has some extras, like 3 stop modes, shutdown mode, nad low power run
<firefrommoonligh>
See `Low-power run mode` section of the RM
<firefrommoonligh>
It looks like the gist of it is re-setup your clocks to the high-speed config at start of `idle`, and at the end, set the LPR bit, and set your clocks to low-speed cfg
<korken89[m]>
Hmm seems like so
<korken89[m]>
I'm trying to find if it is ok to tune the MSI while running from it as well
<korken89[m]>
I can't find something against it though so far
<korken89[m]>
So I only can have like 2 methods
<korken89[m]>
`msi_48mhz()` and `msi_100khz()`
<firefrommoonligh>
I'm not sure. It's likely you'll need to kick off the PLL, wait until it's off, kick off the MSI, wait until it's off, then re set up and turn them back on
<korken89[m]>
I'm not using any PLL
<korken89[m]>
The MSI has all the tuning internally
<firefrommoonligh>
I'm curious if you can change while running, but I think you'll be safe turning it off first for now
<korken89[m]>
I guess one could also jump to the HSI 16MHz temporarily if needed
<korken89[m]>
So not a big issue
<korken89[m]>
I'd just like the RM to tell me if it was needed :P
<firefrommoonligh>
I'm curious what the answer is
<firefrommoonligh>
Just try adjusting while running and see if it works, and appears to have taken the speed adjustment
<firefrommoonligh>
I'm curious about the question of if you need to go to HSI or something while you have MSI ready and adjust it
<firefrommoonligh>
Or if you leave it selected but set it to RDY? But then you don't have an oscillator?
<korken89[m]>
Hmm, set it to RDY?
<korken89[m]>
As I understand it RDY is just that it has converged
<korken89[m]>
It's only a status bit I think
<firefrommoonligh>
Out of curiosity: What's the use case for MSI, or HSI/HSE?
<firefrommoonligh>
* Out of curiosity: What's the use case for MSI, over HSI/HSE?
<korken89[m]>
Selectable frequency
<korken89[m]>
100 kHz to 48 MHz
<korken89[m]>
So like a PLL without needing to start a PLL
<firefrommoonligh>
Gotcha
<firefrommoonligh>
I've been using the "go fast, then sleep" approach - this is situational depending on use
<firefrommoonligh>
* I've been using the "go fast, then stop" approach - this is situational depending on use
<korken89[m]>
Yeah
<korken89[m]>
We will probably go there as well
<korken89[m]>
But I want to start with something simple :)
<firefrommoonligh>
If you feel like tinkering, I like your idea of switching to HSI while adjusting MSI, then switching back. Not sure what the intended way is
<korken89[m]>
Indeed
<korken89[m]>
I mean
<korken89[m]>
If it works it works xD
<korken89[m]>
If it hardfaults I'll try going via HSI
<korken89[m]>
Well then
<korken89[m]>
Just switching the MSI works fine :)
<korken89[m]>
<jamwaffles[m] "korken89: I was doing some L0 st"> Did you need to switch pins to analog and such? I still see ~120 uA too high consumption vs what I am expected in low-power run (should be ~25 uA)
<korken89[m]>
> <@jamwaffles:matrix.org> korken89: I was doing some L0 stuff with RTIC, putting it to deep sleep on button press. That kind of thing?
<korken89[m]>
* Did you need to switch pins to analog and such? I still see ~120 uA too high consumption vs what I expected in low-power run (should be ~25 uA)
<jamwaffles[m]>
I'm still waiting for my nrf-ppk2 so I haven't measured current consumption
<jamwaffles[m]>
Only got as far as making it just work with RTIC
<dirbaio[m]>
the PPK2 is damn unobtainium :(
<jamwaffles[m]>
Yeah... preordered it a long time ago lol
<jamwaffles[m]>
An order of magnitude over my budget haha
<korken89[m]>
xD
<korken89[m]>
True, it's not cheap
<firefrommoonligh>
korken89: are you trying to get that merged into 4xx
<ryan-summers[m]>
jamwaffles: I previously did low-power measurement on the NRF52 using the uCurrent Gold
<ryan-summers[m]>
But beware that the NRF52 has an optional internal LDO or switching regulator. When the switching regulator is on, the current draw from VCC is highly asynchronous (based on when the regulator actually turns on) so it can be difficult to measure actual low current average values
<TimSmall>
jamwaffles: Did you consider the "tinyCurrent-r" - which is a µCurrent clone?
<dirbaio[m]>
I had lots of issues with the uCurrent with dynamic range
<ryan-summers[m]>
Yeah, I had to do a mod on mine to expand the VCC supply
<ryan-summers[m]>
And then used my own custom shunt resistance
<ryan-summers[m]>
The number of configuration settings on it is definitely lacking
<ryan-summers[m]>
Especially when operating with the NRF52 using bluetooth, since you have ~10mA range when the radio enables, but drop down to like nA range when it disables, so you get these huge RC time constants in the uCurrent output
<dirbaio[m]>
spikes (like periodic radio activity) would get "cut", so it was useful to measure the "floor" current consumption but not to average over some minutes to get the "real" current consumption
<ryan-summers[m]>
I eventually had to do post-processing on it using duty cycling to get average current. Measure the radio duration and amplitude, then measure idle current and amplitude and estimate out from there
<dirbaio[m]>
PPK1 has good dynamic range but is 3.6v max, you can't measure at VBAT :(
<dirbaio[m]>
💩
<ryan-summers[m]>
Nowadays I have a battery simulator for managing all this and wow they are great
<ryan-summers[m]>
Could not recommend the Keithley 2281s more
<dirbaio[m]>
3k+ eur, yikes! it better be good for that +D
<dirbaio[m]>
* 3k+ eur, yikes! it better be good for that =D
<ryan-summers[m]>
Yeah it's definitely pricey though
<dirbaio[m]>
we ordered a joulescope last week after getting tired of waiting for the ppk2...
<adamgreig-m>
i wanna get the keithley smu, wonder if it can basically do everything the 2281s does except the nice gui
<adamgreig-m>
I remain mostly happy to not have to do anything where the mcu's power consumption is at all relevant, heh
<TimSmall>
BTW the tinycurrent has a bit better dynamic range (max 3x better) than the original µCurrent, and does at least have the advantage of being cheap (like me): https://github.com/nfhw/tinycurrent
<korken89[m]>
<firefrommoonligh "korken89: are you trying to get "> Not for now, just needed somewhere to prototype :)
<Gireesh[m]>
anyone else having problem with vim+rust analyzer while working on stm32 hal crates?
<Gireesh[m]>
ale is not working correctly for me
<korken89[m]>
with CoC you need to set the appropiate features and target
<korken89[m]>
After that it works for me
<firefrommoonligh>
korken89: I've been back and forth on where low-power entry code goes. It uses registers from cortex-m, pwr, and RCC. I settled on its own module
<firefrommoonligh>
RCC makes sense for the clock-speed changing adn re-initializing PLLs etc, but not for the low-power config, which makes sense in a power module etc
<firefrommoonligh>
So I have a `low_power` module that calls a function from `clocks` to do the clock re-init etc
<firefrommoonligh>
(For example, changing speed to be IOC with LP run mode, or turning the PLL and oscillators back on after stop mode kills and desselects them)
<Gireesh[m]>
<korken89[m] "with CoC you need to set the app"> i thought the same, i am using nvim-lsp need to figure out
<korken89[m]>
CoC + rust analyzer works crazy well
<Gireesh[m]>
probably i should say if i can't figure it out 😂
<Gireesh[m]>
if this doesn't work probably i am going to fall back to coc,
<ryan-summers[m]>
Or just use vim and no analyzer ;)
<agg>
high five, i keep thinking "i should check out these anlysers" and then...
<agg>
though I was playing with onivim2 the other day which can use the vscode r-a plugin and it's quite fun