Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Sys timer should let deep sleep happen #11522
Pull request type
Proposed fixes to #11509
Has been tested with simple blinky example, but should be reviewed and tested by mbed-os core team.
When next SysTimer wake-up is scheduler far enough, always consider that deep sleep may be entered and program an early wake-up. So that even if deep sleep is only allowed some time later, it can be entered. If not doing this, then the deep sleep would be prevented by SysTimer itself and may not be entered at all. This has been proved to happen in a simple blinly example.
Thanks for the investigation.
I've been studying this issue/PR, and considering alternatives. This does work, but does mean we always get double wake-up on boards with latency, even when not deep sleeping.
That's not the end of the world, so maybe it's the way to go, but I was trying a different approach, which was to prepare the timer on the basis of the current
That doesn't work, because changing the timer re-locks the sleep. We get stuck in an endless timer reprogramming loop.
I'm not very happy with the HAL timer drivers locking deep sleep. Seems like a layer violation, and I'm worried it may cause more upsets. Is there any alternative? My assumption was always that the unlock race there would be rare to non-existent, not something that would occur regularly due to a HAL timer interaction with the lock.
So. You need the programming to be complete before entering your deep sleep mode? And that completion generates an interrupt (in which you currently unlock deep sleep?) Could you just have a HAL-local lock - if the "lp timer programming progress" flag is set,
During the extra latency we would be in sleep / WFI which is the same anyway we would have when we can't deep sleep .. so power loss would be insignificant
If doing this, we would actually make all cpu stats wrong. We would tell the system we're in deep sleep when we're not and that could be pretty confusing in the end.
If we return from deep sleep like we do for serial (something we should get rid of one day ...) then we will continuously be executing code in and out of deep sleep (mbed power management layer checks deep sleep is allower, enters deep sleep, u we actually exit immediately, then again .... ) - here the power less can be significant because CPU is active instead of WFI ...
But you're potentially doubling the run-time - a simple LED blink is going to wake twice for every transition. Isn't doubling run-time significant?
Admittedly it's an increase for the intermediate not-deep-sleeping power state, not the actually minimum deep sleep, so maybe it's not that significant.
(Feedback like this is welcome, as I've done quite a lot of work on the sleep stuff, but very much from a theoretical angle - I don't have an intuitive feel for the power/time ratios).
True. That's a good enough argument to dissuade me.
I've also noticed another issue in that when going around again for
So this patch wins for simplicity. I'll review.
@0xc0170 I would really like this PR to be considered for 15.4 release - unless 15.4 is not deployed to the online compiler, mbed studio and so on ... I'd like to avoid having a release where deep sleep is not entered at all after all the efforts we've been through before summer time
I'll run a power measurement on this concrete example and share the results here so that we have concrete data to discuss with.
@kjbracey-arm some data measured today on NUCLEO_L073RZ using mbed-os Blinky example
Deep sleep current ~6µA
Then average MCU power (well average current here) can be considered as :
the fewer wake-ups the better. But the extra wake-up cost when Sleep mode only is possible seems to be low ... the big saving comes when you start entering Deep Sleep