Mbed-os: Echo test in CI sporadically failing

Created on 17 Apr 2018 · 5Comments · Source: ARMmbed/mbed-os

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:

bug

Source

cmonr

All 5 comments

FYI: @studavekar @0xc0170

cmonr on 17 Apr 2018

👍1

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 on 18 Apr 2018

@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

0xc0170 on 23 Apr 2018

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.