Skip to content
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

Update sleep manager tests #7582

Merged
merged 8 commits into from
Oct 10, 2018

Conversation

fkjagodzinski
Copy link
Member

@fkjagodzinski fkjagodzinski commented Jul 23, 2018

Description

Extended tests-mbed_hal-sleep_manager with:

  • deep sleep lock/unlock,
  • deep sleep locked USHRT_MAX times,
  • deep sleep locked more than USHRT_MAX times,
  • deep sleep unbalanced unlock,
  • sleep_auto calls sleep/deep sleep based on lock,
  • deep sleep lock/unlock test_check.

Updated tests-mbed_hal-sleep_manager and tests-mbed_hal-sleep_manager_racecondition test case docs and moved them to test header files.

Pull request type

[ ] Fix
[ ] Refactor
[ ] New target
[x] Feature
[ ] Breaking change

CC @c1728p9 @mprse @jamesbeyond @0xc0170

{
GREENTEA_SETUP(10, "default_auto");
// Suspend the RTOS kernel scheduler to prevent any OS interference.
osKernelSuspend();
Copy link
Member Author

@fkjagodzinski fkjagodzinski Jul 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE:
As @mprse pointed out, when #7524 is merged, this wait should be added here.

#if DEVICE_LPTICKER && (LPTICKER_DELAY_TICKS > 0)
    // After the OS is disabled wait until the microsecond timer
    // is no longer in use by the lp ticker wrapper code.
    // This prevents the low power ticker wrapper code from
    // getting stuck in a state where it is waiting for
    // the microsecond Timeout to run.
    while (lp_ticker_get_timeout_pending());
#endif

* This function is IRQ and thread safe
* Verified by ::sleep_manager_multithread_test and ::sleep_manager_irq_test
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@0xc0170 Is this way of referring tests acceptable? Or should I rather insert a separate defined/undefined behaviour section, e.g. as seen in the ticker API?

* Low level interface to the ticker of a target
*
* # Defined behavior
* * The function ticker_init is safe to call repeatedly - Verified by test ::ticker_init_test
* * The function ticker_init allows the ticker to keep counting and disables the ticker interrupt - Verified by test ::ticker_init_test
* * Ticker frequency is non-zero and counter is at least 8 bits - Verified by ::ticker_info_test
* * The ticker rolls over at (1 << bits) and continues counting starting from 0 - Verified by ::ticker_overflow_test
* * The ticker counts at the specified frequency +- 10% - Verified by ::ticker_frequency_test
* * The ticker increments by 1 each tick - Verified by ::ticker_increment_test
* * The ticker interrupt fires only when the ticker times increments to or past the value set by ticker_set_interrupt.
* Verified by ::ticker_interrupt_test and ::ticker_past_test
* * It is safe to call ticker_set_interrupt repeatedly before the handler is called - Verified by ::ticker_repeat_reschedule_test
* * The function ticker_fire_interrupt causes ticker_irq_handler to be called immediately from interrupt context -
* Verified by ::ticker_fire_now_test
* * The ticker operations ticker_read, ticker_clear_interrupt, ticker_set_interrupt and ticker_fire_interrupt
* take less than 20us to complete - Verified by ::ticker_speed_test
*
* # Undefined behavior
* * Calling any function other than ticker_init before the initialization of the ticker
* * Whether ticker_irq_handler is called a second time if the time wraps and matches the value set by ticker_set_interrupt again
* * Calling ticker_set_interrupt with a value that has more than the supported number of bits
* * Calling any function other than us_ticker_init after calling us_ticker_free
*
* # Potential bugs
* * Drift due to reschedule - Verified by ::ticker_repeat_reschedule_test
* * Incorrect overflow handling of timers - Verified by ::ticker_overflow_test
* * Interrupting at a time of 0 - Verified by ::ticker_overflow_test
* * Interrupt triggered more than once - Verified by ::ticker_interrupt_test

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume as its in ticker (defined behavior + how it is verified)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created a new doxygen section for defined behavior.

@@ -162,6 +162,7 @@ void sleep_manager_lock_deep_sleep_internal(void)
if (deep_sleep_lock == USHRT_MAX) {
core_util_critical_section_exit();
MBED_ERROR1(MBED_MAKE_ERROR(MBED_MODULE_HAL, MBED_ERROR_CODE_OVERFLOW), "DeepSleepLock overflow (> USHRT_MAX)", deep_sleep_lock);
return; // Handle overridden mbed_error(), i.e. when running sleep_manager tests.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This return was added so while running tests, it would immediately return instead of continue (does not trap)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, since I overridden mbed_error() for test purposes and now it does not halt, I had to add this return to prevent execution of following lines -- changing the value of deep_sleep_lock var.

us_diff2 = ticker_read_us(us_ticker) - us_ts;
lp_diff2 = ticker_read_us(lp_ticker) - lp_ts;

TEST_ASSERT_MESSAGE(us_diff2 < lp_diff2 / 4, "Deep sleep mode not used when unlocked");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does 4 come from? what are these 2 lines testing ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now I can see, I didn't provide much explanation here; will add more verbose comments.
This test relies on the fact that us tickers are powered off during deep sleep, and lp tickers stay on for both sleep and deepsleep. The type of sleep that was actually used can be checked by comparing time measured by us and lp tickers.

4 is an arbitrary value. Test checks if us ticker incremented at most 25% of lp ticker time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update with comments

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments added.

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 24, 2018

Please review travis docs failure

@0xc0170 0xc0170 requested a review from a team July 25, 2018 11:37
@fkjagodzinski
Copy link
Member Author

Doxygen generates fine locally, so travis should also be happy with updated code.

@cmonr
Copy link
Contributor

cmonr commented Jul 30, 2018

@0xc0170 @bulislaw @ARMmbed/mbed-os-test Mind re-reviewing?

Copy link
Contributor

@jamesbeyond jamesbeyond left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@fkjagodzinski
Copy link
Member Author

@0xc0170 @bulislaw @c1728p9 could you take a look at this PR?

@fkjagodzinski
Copy link
Member Author

I noticed there was a conflict due to recent astyle update on TESTS dir, so I rebased changes onto current master and update the files using astyle locally.

Although there are no conflicts at the moment, I think this PR could wait for #7524. Both update sleep_manager test files but #7524 looks to be further in the pipeline.

@0xc0170
Copy link
Contributor

0xc0170 commented Aug 22, 2018

Although there are no conflicts at the moment, I think this PR could wait for #7524. Both update sleep_manager test files but #7524 looks to be further in the pipeline.

Already integrated.

Please rebase to resolve the conflict

@mbed-ci
Copy link

mbed-ci commented Sep 28, 2018

@mbed-ci
Copy link

mbed-ci commented Sep 28, 2018

@fkjagodzinski
Copy link
Member Author

Waiting for PR #8279 which will fix the last issue.

Filip Jagodzinski added 8 commits October 9, 2018 17:52
New test cases:
* "deep sleep lock/unlock"
* "deep sleep unbalanced unlock"
* "deep sleep locked USHRT_MAX times"
* "deep sleep locked more than USHRT_MAX times"
* "sleep_auto calls sleep/deep sleep based on lock"
Move sleep manager API into its own doxygen group.
Add defined behavior section and links to tests.
sleep_manager_can_deep_sleep_test_check() is intended to be used in test
code.
Use ticker init functions from upper HAL layer to allow proper handling
of ticker overflows.
Increase delta to 500 us. This value is still short enough to detect
incorrect behavior of the sleep_manager_can_deep_sleep_test_check() fun,
but allows the targets with low LP timer accuracy to pass, i.e.
NUCLEO_F429ZI.
Move a few of utility functions so other tests can use them.
Use us & lp tickers directly, without the common ticker layer.
@fkjagodzinski
Copy link
Member Author

Update:

PR is ready for morph tests again.

@0xc0170
Copy link
Contributor

0xc0170 commented Oct 9, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Oct 10, 2018

Build : SUCCESS

Build number : 3304
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7582/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Oct 10, 2018

@mbed-ci
Copy link

mbed-ci commented Oct 10, 2018

Test : SUCCESS

Build number : 3113
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7582/3113

@cmonr cmonr merged commit 9deefe5 into ARMmbed:master Oct 10, 2018
@fkjagodzinski fkjagodzinski deleted the test_update-sleep_manager branch October 11, 2018 06:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants