Static Thread methods and signal methods have been deprecated. Remove
all references in the main code, and most of the tests. Some tests of
the deprecated APIs themselves remain.
FastModels targets are simulator running on the x86 hosts.
As the nature of non-RealTime x86 OS and FastModels, timing accuracy is not guaranteed
So skipping the time drifting tests on FastModel targets
When the define LPTICKER_DELAY_TICKS is set deep sleep can be randomly
disallowed when using the low power ticker. This is because a Timer
object, which locks deep sleep, is used to protect from back-to-back
writes to lp tickers which can't support that. This causes tests which
assert that deep sleep is allowed to intermittently fail.
To fix this intermittent failure this patch adds the function
sleep_manager_can_deep_sleep_test_check() which checks if deep sleep
is allowed over a duration. It updates all the tests to use
sleep_manager_can_deep_sleep_test_check() rather
than sleep_manager_can_deep_sleep() so the tests work even if deep
sleep is spuriously blocked.
RTX waits, such as sem.wait(N), delays for between N-1 and N cycles.
As lp_ticker is not so accurate as us_ticker,
sometines, wait is expiring just before the lp_timeout.
The test sometimes fails on NRF51_DK (test case: "Test: LowPowerTimer - time measurement 1 ms.") in morph tests.
The test verifies if LowPowerTimer class correctly counts elapsed time. Sometimes we got measured ~1600 us 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 rescheduling/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 measurement of 1 ms 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).
Make multiticker test more reliable when scheduling very early interrupts.
When very early interrupt is scheduled (e.g now + 2[ticks]) then it's likely
that it won't be fired in some circumstances and as a result there is overdue
event in queue. That overdue event can be mistakenly scheduled again by
`Ticker::detach` (detach calls schedule if head was removed). That's why we
should check interrupts counter immediately after wait period and before detach loop
Test inserts event into the TimerEvent object which is scheduled 50 ms in the future. Then test thread hangs on the semaphore for 51 ms and after that time we expect that event handler has been executed. This test fails sometimes on NRF51_DK, NRF52_DK since different clocks are used for event handling and delay. TimerEvent class uses fast us ticker and semaphores are based on lp ticker (NRF51_DK) or System Tick Timer (NRF52_DK).
We assume that ticker measurement error is 10% and our 1 [ms] extra corresponds to 2% error. I suggest to increase delay to 2 [ms] (4%). This should be enough for all boards at this moment.
This test fails sometimes while testing 1 ms timeout on NRF51_DK board.
This board is very slow and lp ticker is inaccurate.
I noticed that measured results are very close to the tolerance value. For 1ms delay we measure in failure case 1560 us and tolerance is set to 550.
Since measurement method is also significantly flawed (extra time for setting up ticker and execution of a ticker irq handler) I recommend to increase tolerance by least +100 us for now.
Since now us ticker is disabled in deep-sleep mode and tests-mbed_drivers-timerevent verifies TimerEvent class which uses us ticker then deep-sleep mode needs to be disabled during the test execution.
Since this change concerns new ticker driver for NRF51_DK it goas on ticker feature branch.
On this branch us ticker is based on 1 MHz higher precision counter (on master is based on 32kHz RTC). As a result of using higher precision counter measurement error increased:
:485::FAIL: Expected 1.060000 Was 1.070478
For delay 1060 ms we measured ~1070 ms so we have about ~1% measurement error which is not bed for this board.
To make it work with 1MHz us ticker increase test tolerance. Define tolerance as follows:
tolerance = 500us + 0.02 * delay.
Since this change concerns new ticker driver for NRF51_DK it goas on ticker feature branch.
On master NRF51_DK Ticker driver uses 32kHz RTC for lp and us ticker. Test uses us ticker to measure lp ticker interrupt scheduling (LowPowerTicker.attach), but since the same hardware is used for both tickers the measurement error is constant. On this branch us ticker uses 1 MHz higher precision clock and the results are different - measurement error grows linearly and shows inaccuracy of the RTC.
Test implements constant delta for measured time equal to 2000 us.
Change delta so it depends on lp ticker tested timeout value:
500us for measurement inaccuracy + 5% tolerance for LowPowerTicker
Since target specific ticker drivers are not ready also features which uses ticker in upper layers may not work correctly and tests for these features.
We need to disable also failing higher level ticker related tests (by adding check if DEVICE_USTICKER symbol is available and raise #error [NOT_SUPPORTED] if not).
Note:
tests-mbed_drivers-rtc is new and uses us ticker to perform a delay.
Since target specific ticker drivers are not ready also features which uses ticker in upper layers may not work correctly and tests for these features.
We need to disable also failing higher level ticker related tests (by adding check if DEVICE_USTICKER symbol is available and raise #error [NOT_SUPPORTED] if not).
These boards will be re-enabled when sleep driver for them is ready.
Note:
This operation is done by removing "SLEEP" feature from target's "device_has" list (in targets.json config file).
For NRF52_DK removing of "SLEEP" feature causes some timing issues which have influence on tests. In order to successfully disable this board we need to disable also related features like "USTICKER", "LOWPOERTIMER" and slightly modify ticker tests, so they will not be executed if usticker support is not available (by default all targets support us ticker).
Currently test assumes that 1 sec is long enough to set RTC time and read same time which has been set.
In some cases extra time for synchronisation between clock domains is needed and after setting/reading operations the read value might be different than one which has been set (+1 sec).
Additionally in some cases when lp ticker is based on RTC, the RTC implementation may use mechanism to trace elapsed seconds without modifying RTC registers. In such case it is possible that second will change immediately after setting time.
Add 1 sec tolerance (min possible) for such checks.
Previously, the echo test followed a flow like the following:
-STEP- -HOST PC- -DEVICE-
0 send _sync
1 echo back _sync
2 send echo_count
3 echo back echo_count
4 send first echo packet
5 echo back echo packet
(repeat echo steps)
However, as noted by issue #6659, this test would somtimes fail between
steps 4 and 5. To ensure each KV pair makes to the correct destination,
we usually write the KV back. Step 4 does not wait for this to happen
and starts sending echo packets. So the device is acting as the "echo
server".
This change makes the host PC the "echo server". The idea being that the
device will be slower and the host pc should always be able to keep up
with it, not the other way around.
David Saada
kegilbert
Martin Kojtal
Kevin Bracey
Cruz Monrreal
Qinghao Shi
deepikabhavnani
Russ Butler
Nir Sonnenschein
Maciej Bocianski
jeromecoutant
Przemyslaw Stekiel
ccli8
Wilfried Chauveau
Bartek Szatkowski
Brian Daniels
Filip Jagodzinski
Cruz Monrreal