RTC reset test was failing when board has been just powered and RTC reset test was executed for the first time (issue has been detected on CI). In such case RTC initialization takes more time than in futher rtc_init calls. This has impact on green-tea communication. Commands send by host immediately after init command (write, read) were not handled on the device side and no response to the host was provided.
To fix this problem test communication flow has been modified. Device sends ack to the host after RTC init is done. Host sends further RTC commands when ack from the device has been received.
Edit:
There are still some communication issues on the CI. Add ack from the device after each executed command. Increase test timeout and wait after reset.
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.
For each of the following years test example time of the first and last day of each month:
- first - 1970
- example not leap year (not divisible by 4)
- example leap year (divisible by 4 and by 100 and by 400)
- example leap year (divisible by 4 and not by 100)
- example not leap year (divisible by 4 and by 100)
- last fully supported - 2105
Test execution time on K64F is now ~39 sec.
In the new approach the host controls the device activity when the test
should start, finish and pass/fail status is send to device. Also deprecate
the test cases which can't accurately test.
The timing host tests reported success even if the total drift was
negative. This adds a check for this now.
The wait_us test now does not use a timer and just waits for 100000 us
between prints. This adds inherent drift, but it should still be well
under the limit.