-
Notifications
You must be signed in to change notification settings - Fork 3k
tests-mbed_drivers-timer: change delay method #7752
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
tests-mbed_drivers-timer: change delay method #7752
Conversation
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.
👍 for the detailed description.
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.
Look good
/morph build |
Build : SUCCESSBuild number : 2783 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 2414 |
Test : SUCCESSBuild number : 2520 |
tests-mbed_drivers-timer: change delay method
Description
The test sometimes fails on NRF51_DK (test case: "Test: Timer - time measurement 1 ms.") in morph tests.
Fail log
The test verifies if Timer class correctly counts elapsed time. Sometimes we got measured ~1600us for delay 1000 us (delta 550 us). The delay is performed using wait_us() function which for delays greater than or equal to 1 ms (our case) calls Thread::wait((uint32_t)ms);. This causes rescheduling and potentially can put board into sleep (deep sleep mode is disabled by wait_us()). For our test purposes we don't need escheduling/sleep since this actions takes extra time and have influence on the time measurement accuracy. The solution is to implement function for delay which is based on busy loop and uses us ticker. It has been verified that this solves the problem. With this fix when test case is repeated 1000 times we got usually measured time equal to ~1080 us, and sometimes ~1300us (checked that this is caused by systick interrupt handling). Since this is test for drivers layer and the results are acceptable I decided to not disabling systick in the test).
Related PR's: #7471
Pull request type