A DTR line is used to signal that the host has configured a terminal and
is ready to transmit and receive data from the USB CDC/Serial device.
When this test suite is run with the use of a Linux host, a workaround has
to be used to overcome some platform specific DTR line behavior.
Every time the serial port file descriptor is opened, the DTR line is
asserted until the terminal attributes are set.
As a consequence, the device receives a premature DTR signal with a
duration of 200-500 us before the correct, long-lasting DTR signal set by
the host-side test script. (tested on the Linux kernel 4.15.0)
The solution is to wait for the first DTR spike, ignore it, and wait for
the correct DTR signal again.
Update the serial host test to set DTR low before opening a serial
port. Set DTR high once the serial object is ready. This ensures that
no data is sent by the device until the host is ready.
Fix the host script issues present on Windows machines.
Add 0 B payload size to bulk endpoints test.
Update halt and abort tests according to PR comments.
Add an explicit request to start reading on OUT endpoints.
Change the base time value to more realistic:
START_TIME = 1537789823 # GMT: Monday, 24 September 2018 11:50:23
This fix has been proposed by STM in order to enhance test efficiency.
Current test version did not detect problem with RTC reset on F1 family boards since the base time was too small.
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.
Maciej Bocianski
Russ Butler
Filip Jagodzinski
Filip Jagodzinski
Senthil Ramakrishnan
Brian Daniels
Cruz Monrreal
Shrikant Tudavekar
Przemyslaw Stekiel
David Saada
Amir Cohen
Bartek Szatkowski