9 years ago.

Follow-up on "singletest.py: need wait between end of copy to target and serial port initialisation"

Hi again. I'm now using a merge of Przemek Wirkus's [thanks Przemek!] push request from here:

https://github.com/mbedmicro/mbed/pull/986

...and it has definitely improved things as tests do now download and run. However, it's not completely reliable. For instance, running test MBED_A1 five times gives me:

TargetTest::LPC1768::GCC_ARM::MBED_A1::Basic [TIMEOUT] in 20.48 of 10 sec TargetTest::LPC1768::GCC_ARM::MBED_A1::Basic [TIMEOUT] in 20.49 of 10 sec TargetTest::LPC1768::GCC_ARM::MBED_A1::Basic [OK] in 1.36 of 20 sec TargetTest::LPC1768::GCC_ARM::MBED_A1::Basic [OK] in 1.34 of 20 sec TargetTest::LPC1768::GCC_ARM::MBED_A1::Basic [TIMEOUT] in 20.47 of 10 sec

In general I get a timeout about 1/3 of the time. Running with -v and looking at a fail case, it says:

Executing 'python host_test.py -d D: -f "C:\projects\mbed\build\test\LPC1768\GCC_ARM\MBED_A1\basic.bin" -p COM31 -t 10 -C 1.5 -m LPC1768'
Test::Output::Start
MBED: Instrumentation: "COM31" and disk: "D:"
HOST: Copy image onto target...
HOST: Initialize serial port...
....port ready!
HOST: Reset target...
HOST: Unknown property:
HOST: Unknown property:
HOST: Unknown property:
HTest::Output::Finish

The first Unknown propery: is sometimes followed by { or {{timeout;2. I've tried adding a 5 second "reset_tout" delay but that doesn't seem to help. Is there a more detailed level of debug I could look at to find out what's going wrong? Looking at the C027 board it's difficult to correlate when the problem occurs with the behaviour of the LEDs, but it is something to do with the end of the copy and the reset I guess. What else could I do to make this reliable?

Question relating to: