2022-07-03 09:57 AM
I'm new to the STM32L053R8, and I'm trying to emulate a configuration I've used on other ARM M0+ systems.
Ideally, I want to maintain a 32 bit counter (physical or virtual) clocked at 32KHz so I have ~30 uSec resolution with a ~131K second roll-over interval. Then I want to put the processor into *some* low power mode (I'm not picky, but the lower the better) and have it wake up when the counter matches an arbitrary 32 bit value that was set prior to sleeping.
It's possible I could torture the RTC into doing this, but it seems unlikely. Ganging together TIM21 and TIM22 seems more likely, but is there a way to get them to wake the processor without resorting using GPIO pins and external components?
(Side note: if this really isn't practical on the STM32L053Rx, I'll probably settle for a 16 bit counter clocked at 1KHz, so I have 1 mSec resolution with 65 second roll-over and synthesize longer timeouts in software.)
2022-07-03 01:32 PM
These are two questions: one is around extending 16-bit timer to 32-bit, and the other is the wakeup. I assume you can solve the latter yourself, it's mostly about reading the PWR and EXTI chapters in RM, and extensive experimentation (which you can do with the 16-bit timer alone, too). I don't have much experience with sleeps.
Now, as I've said, the real quest is to read out the 32-bit value from two timers coherently. But if you don't need to maintain a running timekeeper, just have something to wake you up, then it's about setting up the two timers as master-slave, set perhaps some starting value so that the slave rolls over exactly when the required time elapses, run them and go to sleep.
If the 32-bit value does not need to be entirely arbitrary and some slack can be allowed, you may even be good with factoring it into two 16-bit value to be used within one timer, in prescaler and counter (note though that prescaler is unconditionally preloaded).
Note, that timers don't allow very low power modes, as they need some peripheral clock running, but the LPTIM does. However, that may be even trickier to use.
JW
2022-07-03 03:22 PM
I'm leaning towards just using a 16 bit timer and use CC1I to unconditionally generate interrupt on overflow every ~65 seconds -- I'll use that to increment a high-order 16 bit counter. (I'll still have to test for the coherency issue that you pointed out when reading it as a 32 bit counter.) In addition, if I want a wake-up interrupt before 65 seconds have elapsed, I'll use CC2I for that.
At least, that's my current thought.
2022-07-03 11:26 PM
That's an option, too; although you don't need to use CC1 for interrupt upon overflow, you can use the Update interrupt for that.
JW
2022-07-07 07:09 AM
@Community member Thanks for the update interrupt hint.
By the way, any idea why we're getting "slightly edited" copy/paste replies from previous replies (e.g. @ddjwk.1 and @kdfd.1 replies) -- are these bots or what?
2022-07-07 08:57 AM
Bots or human, spammers ultimately. They probably evade any automated antispam by this copy/dictionary-replace/paste mechanism which is likely automated, and then appear to inject the actual spamming link later, when the post "sticks".
There's a "Flag" option under the small arrow at the right upper corner of the post, which can be used to draw attention of Moderators to these posts.
JW