-
Notifications
You must be signed in to change notification settings - Fork 3k
Changes required by the ST low power ticker wrapper. #10536
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -122,8 +122,27 @@ void deepsleep_lpticker_test() | |
|
||
lp_ticker_set_interrupt(next_match_timestamp); | ||
|
||
/* On some targets like STM family boards with LPTIM enabled there is a required delay (~100 us) before we are able to | ||
reprogram LPTIM_COMPARE register back to back. This is handled by the low level lp ticker wrapper which uses LPTIM_CMPOK interrupt. | ||
CMPOK fires when LPTIM_COMPARE register can be safely reprogrammed again. During this period deep-sleep is locked. | ||
This means that on these platforms we have additional interrupt (CMPOK) fired always ~100 us after programming lp ticker. | ||
Since this interrupt wakes-up the board from the sleep we need to go to sleep after CMPOK is handled. */ | ||
TEST_ASSERT_TRUE(sleep_manager_can_deep_sleep_test_check()); | ||
|
||
sleep(); | ||
|
||
/* On some targets like STM family boards with LPTIM enabled an interrupt is triggered on counter rollover. | ||
We need special handling for cases when next_match_timestamp < start_timestamp (interrupt is to be fired after rollover). | ||
In such case after first wake-up we need to reset interrupt and go back to sleep waiting for the valid one. | ||
NOTE: Above comment (CMPOK) applies also here.*/ | ||
#if MBED_CONF_TARGET_LPTICKER_LPTIM | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why this very target specific config (_LPTIM) is here in the test? Is this documented anywhere - this "unwanted" wake up from sleep There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So in the case of The extra interrupt on
|
||
if ((next_match_timestamp < start_timestamp) && lp_ticker_read() < next_match_timestamp) { | ||
lp_ticker_set_interrupt(next_match_timestamp); | ||
wait_ns(200000); | ||
sleep(); | ||
} | ||
#endif | ||
|
||
const timestamp_t wakeup_timestamp = lp_ticker_read(); | ||
|
||
sprintf(info, "Delta ticks: %u, Ticker width: %u, Expected wake up tick: %d, Actual wake up tick: %d, delay ticks: %d, wake up after ticks: %d", | ||
|
@@ -154,11 +173,14 @@ void deepsleep_high_speed_clocks_turned_off_test() | |
|
||
TEST_ASSERT_TRUE_MESSAGE(sleep_manager_can_deep_sleep(), "deep sleep should not be locked"); | ||
|
||
const unsigned int us_ticks_before_sleep = us_ticker_read(); | ||
|
||
const timestamp_t wakeup_time = lp_ticker_read() + us_to_ticks(20000, lp_ticker_freq); | ||
lp_ticker_set_interrupt(wakeup_time); | ||
|
||
/* Wait for CMPOK */ | ||
TEST_ASSERT_TRUE(sleep_manager_can_deep_sleep_test_check()); | ||
|
||
const unsigned int us_ticks_before_sleep = us_ticker_read(); | ||
|
||
sleep(); | ||
|
||
const unsigned int us_ticks_after_sleep = us_ticker_read(); | ||
|
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.
how is this handled in the target code? Does not need to be there - scheduler schedule sleep, deep sleep would be locked, ~100us wake up, nothing to do, goes again to sleep - this time deep sleep.
Do I understand this correctly ?
Because seeing this in the common test file raises questions if a target does nto handle this internally and how to write generic sleep handling.
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.
Because this a HAL test, there is no scheduler involved here I think
Here is how I commented the same for sleep manager test
https://github.com/ARMmbed/mbed-os/pull/10700/files#diff-5d28bad27b5517915180d28407cb8c79R125
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.
So with scheduler anything above HAL, we are all good and this checks are not needed - will wake up - nothing to do, goes to sleep again (causing one false wake up only).
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.
exactly !