-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STM: replace C++ low power ticker wrapper with a low level wrapper #10701
STM: replace C++ low power ticker wrapper with a low level wrapper #10701
Conversation
365dcb2
to
ca90405
Compare
Updated the changes in targets.json to disable the wrapper only for STM32 targets that use the LPTIM HW (not RTC HW) and have TICKLESS enabled (L0, L4, WB, F7, H7 and few F4 boards). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
I added only a few minor suggestions.
20c89e3
to
4b69cd7
Compare
@mprse could you please review the latest updates ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
7315031
to
fbb38c0
Compare
and rebased to solve conflicts ... |
Note: once this gets merged, Tickless will be fully active on the STM32 targets impacted by this PR, ie with dynamic Deep sleep entry / exit by default ... |
There is an errata in LPTIM specification that explains that CMP Flag condition is not an exact match (COUNTER = MATCH) but rather a comparison (COUNTER >= MATCH). As a consequence the interrupt is firing early than expected when programing a timestamp after the 0xFFFF wrap-around. In order to work-around this issue, we implement the below work-around. In case timestamp is after the work-around, let's decide to program the CMP value to 0xFFFF, which is the wrap-around value. There would anyway be a wake-up at the time of wrap-around to let the OS update the system time. When the wrap-around interrupt happen, OS will check the current time and program again the timestamp to the proper value.
LP TICKER mbed-os wrapper needs to be disabled as it introduces too much latencies. LP TICKER wrapper has been disabled and we need to managed the HW constraints at low level: - main HW constraint is that once the comparator has been programmed once, driver cannot program it again before CMPOK HW flag is set, which takes about 3 30us cycles. To make it even more complex, the driver also needs to cope with "LP ticker workaround" See commit: LP ticker workaround There is an errata in LPTIM specification that explains that CMP Flag condition is not an exact match (COUNTER = MATCH) but rather a comparison (COUNTER >= MATCH). Also the disable interrupt is more complete now: - always check sleep manager status and restore it - remove irq_handler as comparator is always programed and might get called eventually when LP TICK is restarted - reset delayed_prog Also in set_interrupt, make sure interrupt does not fire early. If needed, we decide to slightly delay the tick to cope with the HW limitation to make sure it will fire as soon as HW is capable. Functions are called under critical section as they may be called from the IRQ handler now, not only from driver layer.
For L0/L4/H7/F7/WB targets that have tickless enabled, remove the tickless from us ticker and the delay ticks as the C++ wrapper layer is being removed and replaced by the low layer handling. For now, the few F4 targets with LPTIM are left with previous configuration as test results are showing a few instabilities not yet understood.
Now we'd rather not use this wrapper and use instead the low level wrapper implemented in this driver.
fbb38c0
to
6331034
Compare
Rebased again to solve conflicts on targets.json ... Thanks @c1728p9 for approving ! |
CI started |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
Ready to merge? |
Just reviewing all needs: CI, a sec ! |
Thank you all - let's Tickless now :-) |
I just came back from holidays and I can see that this one has passed CI and has been merged. |
@mprse thanks to you ! |
Description
This series of commits aims at removing the latency limitation of the LP ticker wrapper.
Current situation is that workaround from #9785 makes TICKLESS actually work without real deep sleep usage. #9785 was introduced because of latency issue with the C++ wrapper layer.
With this Pull request the C+ wrapper layer is removed and replaced by a low level wrapper in lp ticker driver of STM targets. This direction was suggested by @c1728p9 and supported by @mprse
Implementation of this low level wrapper require many specific implementation detailed in separate commits because of the way the LP TIMER HW is designed.
In particular, the LP TIMER ticker cannot be programmed for a timestamp in the past, so we need to program a wake-up interrupt at the wrap-around (0xFFFF), then the next interrupt will be programmed again. Also the LP TIMER cannot cope with programming an interrupt within the next few low power clock 32KHz cycles, corresponding to the time it takes for CMPOK flag to be set, which means new comparator value is taken into account. Those design constraints are taken into account in this new implementation.
The changes in this pull request have dependencies to a few test cases updates:
#10536 #10698 #10700
Also changes to IDLE stack size are needed:
#10702 #10781
Also this PR supersedes #10537 that will be closed. The commit from #10537 is actually included in this new PR.
This PR should also solve #9962 and it reverts #10572 by enabling back LPTIM on NUCLEO_L073RZ.
Pull request type
Reviewers
@c1728p9 @mprse @jeromecoutant
Release Notes
The test results are good and show significant improvements on latencies.
@mprse has verified that interrupt latencie is now lower than it was, allowing reliable serial communication @115200kbps on NUCLEO_L476RG target and 57600kbps on NUCLEO_L073RZ.
Complete test suites have been run on
TOOL_CHAIN=ARMC6,GCC_ARM,IAR
Executed targets : ['NUCLEO_WB55RG']
Executed targets : ['NUCLEO_L476RG']
Executed targets : ['NUCLEO_L073RZ']
And there is still a pending issue to be understood that might come from common ticker layer and was not seen before. @mprse is looking at it.