-
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
STM32 LPTICKER : Fix tickless and LPTICKER_DELAY_TICKS #8242
Conversation
Note that my TICKLESS tests was including #8223 |
I don't think so, you can start CI |
}, | ||
"lpticker_delay_ticks": { | ||
"help": "https://os.mbed.com/docs/v5.9/reference/low-power-ticker.html", | ||
"value": 1, |
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.
Why is only one cycle needed?
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.
Good idea for the link. Just maybe replace "v5.9" with "latest".
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.
In some previous patch, I have removed this delay tick, but it seems that not all the tests can pass...
Then I set back value to 1 as the default value.
} | ||
}, | ||
"overrides": {"lpticker_delay_ticks": 4}, |
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.
Why are 4 needed for the L series?
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.
Default value 1 seems not enough for low speed targets.
4 is the experimental result to pass speed test.
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.
Is there anything in the reference manual for these devices which state the number of cycles which must elapse before writing to the match register?
@@ -263,7 +258,6 @@ uint32_t lp_ticker_read(void) | |||
|
|||
void lp_ticker_set_interrupt(timestamp_t timestamp) | |||
{ | |||
lp_ticker_disable_interrupt(); |
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.
Do you have any details on how this fixes the test in #8129?
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.
yes, I should add the details you have added in #8129
@@ -194,21 +191,22 @@ void lp_ticker_set_interrupt(timestamp_t timestamp) | |||
LptimHandle.Instance = LPTIM1; | |||
irq_handler = (void (*)(void))lp_ticker_irq_handler; | |||
|
|||
__HAL_LPTIM_CLEAR_FLAG(&LptimHandle, LPTIM_FLAG_CMPOK); | |||
__HAL_LPTIM_COMPARE_SET(&LptimHandle, timestamp); | |||
/* CMPOK is set by hardware to inform application that the APB bus write operation to the LPTIM_CMP register has been successfully completed */ | |||
/* Any successive write before the CMPOK flag be set, will lead to unpredictable results */ | |||
while (__HAL_LPTIM_GET_FLAG(&LptimHandle, LPTIM_FLAG_CMPOK) == RESET) { |
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.
Will this bring back the blocking behavior?
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.
No, it is the same behavior as you have done in #8129
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.
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.
@c1728p9 my mistake - Jérôme explained to me and I actually misunderstood CMPOK (programing ok) with CMPM (comparator match) - looks ok to me now
Removing, I understood it otherway around |
This fixes issue with mbed_hal/lp_ticker/lp_ticker_early_match_race_test
When both tickless and LPTICKER_DELAY_TICKS are enabled some ST devices randomly get stuck sleeping forever. This is because the wake up time passed to the rtc is ignored if the previous match is about to occur. This causes the device to get stuck in sleep. This patch prevents matches from getting dropped by the rtc by deactivating the rtc wake up timer before setting a new value. Events leading up to this failure for the RTC: -1st call to lp_ticker_set_interrupt -delay until ticker interrupt is about to fire -2nd call to lp_ticker_set_interrupt -interrupt for 1st call fires and match time for 2nd call is dropped -LowPowerTickerWrapper gets ticker interrupt but treats it as a spurious interrupt and drops it since it comes in too early -device enters sleep without a wakeup source and locks up
For both implementation, RTC and LPTIM, there is some delay in the set_interrupt function due to HW constraints. Value has been set to 4 for STM32L0, because SystemClock is slower than other families.
4c94e30
to
af4841d
Compare
Rebase done. @c1728p9 maybe you can approve and start CI ? Thx |
/morph build |
Build : SUCCESSBuild number : 3203 Triggering tests/morph test |
Test : FAILUREBuild number : 3003 |
Exporter Build : ABORTEDBuild number : 2795 |
Test needs to be restarted (device was power cycled) and exporters as well, will do once we fix exporters CI job |
/morph test |
Test : SUCCESSBuild number : 3038 |
/morph export-build |
Exporter Build : SUCCESSBuild number : 2841 |
Description
This should fix #7858,
and is needed to pass new test case from #8129
@c1728p9
Test result
With that patch, all tests are OK in default mode and in TICKLESS mode for targets using LPTICKER with LPTIM.
I will push a separate PR to enable TICKLESS for them.
Restriction
In tickless mode, for targets using LPTICKER with RTC, it seems there is still some issue
with the RTC write procedure.
I will push a new PR when solution is found.
Pull request type