-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
Target:
NUCLEO_F103RB
Toochain:
Arm
MbedOS:
mbed-os-5.9.0-rc3
Test case:
mbedmicro-mbed\call_before_main
While running one of the mbed tests on the NUCLEO_F103RB, we noticed an issue where htrun complained about receiving a byte it cannot decode. The test ran fine on other targets. Narrowing it down further, it seemed like the problem is on the host target. Whenever we flush out the stdout using '\n' or fflush, and the uart gets reinitialized for next stream of data, the very first character it sends is something unusual ('255', or '254') which is causing the issue.
I am attaching snapshots of the data captured from logic analyzer, and you can see the decay on analog during reinitialization.
In this snapshot, you can see the ascii value of the character sent right after reinitialization ('255')
This behavior is reproducible each time.
Steps to reproduce
mbed test -m NUCLEO_F103RB -t ARM -n tests-mbedmicro-mbed-call_before_main -v
[ ] Question
[ ] Enhancement
[X ] Bug
@ARMmbed/team-st-mcd
@screamerbg
See, ARMmbed/greentea#278, once this issue is fixed for all partners, revert the change made for greentea