Echo test in CI sporadically failing

[cmonr]

Description

• Type: Bug
• Related issue: N/A
• Priority: Major

---

Bug

Target
Multiple

Toolchain:
Multiple

Expected behavior
CI test should be stable and only fail for valid reasons.

Actual behavior
CI Tests builds have started randomly failing the mbed_drivers/echo test.

Steps to reproduce
TBD.

Notes

The most recent failures can be found here:

• http://mbed-os-logs.s3-us-west-1.amazonaws.com/logs/6468/1513/FAIL/EV_COG_AD3029LZ/ARM/test_report_EV_COG_AD3029LZ-ARM.html
• http://mbed-os-logs.s3-us-west-1.amazonaws.com/logs/6603/1565/FAIL/KW41Z/GCC_ARM/test_report_KW41Z-GCC_ARM.html
• http://mbed-os-logs.s3-us-west-1.amazonaws.com/logs/6603/1570/FAIL/KW24D/IAR/test_report_KW24D-IAR.html
• http://mbed-os-logs.s3-us-west-1.amazonaws.com/logs/6620/1544/FAIL/EV_COG_AD4050LZ/IAR/test_report_EV_COG_AD4050LZ-IAR.html
• http://mbed-os-logs.s3-us-west-1.amazonaws.com/logs/6627/1560/FAIL/K82F/IAR/test_report_K82F-IAR.html
• http://mbed-os-logs.s3-us-west-1.amazonaws.com/logs/6634/1543/FAIL/EV_COG_AD4050LZ/IAR/test_report_EV_COG_AD4050LZ-IAR.html

[cmonr]

FYI: @studavekar @0xc0170

[0xc0170]

This type of test should be functional always if the rest is (host client communication is working). I do not recall any change to the test itself (its python counterpart). Where else it could be ?

[0xc0170]

@kegilbert @cmonr this is still an issue that affects master.

From quick discussion with @studavekar this is generic failure, might be related to the load on the host. When I checked the history of the file there were 2 changes done long time ago. Few more boards recently failed this test - k82f, kw24d.

Do we need any delay after sending echo? Or using something else than getc (our tokenizer uses it currently). Alternate between tx/rx/tx/rx?

cc @kjbracey-arm

[kjbracey]

My supposition was that as you are using "raw" unbuffered serial, you are totally reliant on the device being ready and receiving - spinning in serial_getc whenever data comes in. This sort of reception is pretty dicey - normally you would need an interrupt handler for reliable reception (using UARTSerial eg by turning on platform.stdio-buffered-serial would do this).

In this case I'm guessing the time spent to parse the echo back echo_count from the host is long enough that it doesn't get back to serial_getc in time for the first byte of the first echo packet.

So I think your patch should resolve it - you're no longer ever getting two packets in a row from the PC.

[cmonr]

Closing since PR has been brought in.