search

ARMmbed / htrun

MOVED: https://github.com/ARMmbed/mbed-os-tools (Flash, reset and run host supervised tests on mbed platforms)
8 stars 37 forks source link

Reset device after bad sync #200

Closed aashishc1988 closed 6 years ago

aashishc1988 commented 6 years ago

To solve issue: https://github.com/ARMmbed/htrun/issues/193

Solution:

The host would send an initial sync, and if it receives a bad sync it will reset the part and wait until a certain duration before sending the second sync packet. Meanwhile, if it receives another sync packet from DUT (if the buffer was not empty), it will reset the part again. Corner case: The DUT has 4 bad syncs in its buffer, and when it sent out the 3rd one, host received it and told it to reset, and then host itself reached a stage where it is ready to send second sync. At this point, device sends out the 4th sync and begins executing the tests (since there is no ack from host), and this test is one of those kind where it would continuously spew out data to host via the buffer, in this case, sending second sync would have no effect because that stage has already passed. At this point, host will not receive any echo back from device and it would eventually time out. To solve this particular corner case, while sending second sync, we should reset the device first and then send second sync packet.

coveralls commented 6 years ago

Coverage Status

Coverage decreased (-0.2%) to 43.541% when pulling 123670ee0d5e3647ed95bd7e25d34a1bd79ae00c on aashishc1988:reset_bad_sync_protocol into 51edce4f3e3f32b254678f4640c4ec30844c2a7a on ARMmbed:master.

aashishc1988 commented 6 years ago

Yes, I think that is a good idea :) Every time a faulty sync comes, reset the timeout to send fresh sync and keep listening for another sync (if any) from client, and then eventually send the new sync.

aashishc1988 commented 6 years ago

@bridadan Added the fix.