ARMCC serial fails to connect properly with pc serial application

[TaniaMirzin]

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Bug
• Priority: Major

---

ARMCC serial in debug mode fails to connect properly with pc serial application

Target
K64F

Toolchain:
ARM

Toolchain version:
DS-5_v5.25.0/ARMCompiler5.06u3

mbed-cli version:
1.2.0
mbed-os sha:
caeaa49 5.7.4

Expected behavior
The device application reads and send all data via Serial.

Actual behavior
The application stuck and fails to send data to windows application.

Reproduce steps
(These steps placed infactory-configurator-client-example-internal repository branch restore_armcc_serial in README.rd)
To clone the Factory Client repository -

git clone git@github.com:ARMmbed/factory-configurator-client-example-internal
Use branch:
restore_armcc_serial

Prepare all libraries for restore process:
cd devenv\internal-scripts
python switch-repos.py master-dev

Compile serial application from for GCC_ARM and for ARM:
cd ../../
./build-mbed-os.sh --toolchain=ARM --platform=K64F --iface=FCE_SERIAL_INTERFACE
or
cd ../../
./build-mbed-os.sh --toolchain=GCC_ARM --platform=K64F --iface=FCE_SERIAL_INTERFACE
this will comiple the simple application source/factory_client_example.cpp

Run the application
Copy source/fce_serial_tester.py python script to windows.
Copy compiled application image to your K64F device.
Reset the device.
Run python scritp :
python fce_serial_tester.py --port COM8
Change COM8 to your active COM number.

Expected behavior for all toolchains:
The python application should inject message (1913 bytes) to the device by Serial connection.
Device reads all 1913 bytes using Serial object and send the data back to serial.
The python application reads first 500 bytes that was sent by the device and prints it.

Actual behavior:
For GCC_ARM the application acts as expected.
For ARM the application fails to connect back with python script and the scripts failes to read and print any data from device.

---

[TaniaMirzin]

@kjbracey-arm https://jira.arm.com/browse/IOTMORF-2064

[TaniaMirzin]

@kjbracey-arm this relevant only for debug mode

[kjbracey]

Looking at it, this code seems like it may always be unreliable. Serial doesn't really work well for input for a number of reasons. See #5655.

I've never seen anyone successfully use Serial for input without bypassing the top-level Serial::getc and going to the underlying SerialBase from interrupt handler,

While waiting for input, you will be consuming 100% of CPU time, spinning on checking the serial port. Now, I guess that may be actually make the read responsive enough without interrupt handling IF you have no other threads.

This could be ultimately timing related, but the ARMCC debug build is the only one slow enough to hit it?

I would suggest you change to using UARTSerial, which will buffer the data in the background under interrupt, so you can read at your leisure, and not spin the thread while waiting.

Things to check:

• The serial will only work if you've already entered your _serial_read by the time the other end starts sending. Is there enough start-up delay and further handshaking to make sure you're _serial_reading in time? UARTSerial's buffer would totally or largely eliminate this problem.
• Is mbed-trace enabled? That serial stuff could interfere by slowing down your entry to read.
• Can you tell where it's getting stuck? Is it that _serial_read is stopped a couple of characters short due to a couple of losses? As it stands that's going to rely on 100% serial port reliability, no character loss. As you're packet-based, maybe you could add a timeout so that after getting the first character it gives up if it doesn't get the requested amount in a couple of seconds?

[TaniaMirzin]

@kjbracey-arm
Regarding your first point :

• For our use case we always used the scenario when the device application enters to _serial_read and waits until it gets a data. It is OK with us that the application consuming 100% of CPU, as we don't expect from it to perform anything else. In most of our runs the device application enters _serial_read before the second application even starts sending, but it always worked for us (GCC is still working in a such way).
  Second:
• No mbed-trace is not enabled.
  The last one:
  -The application reads all the data by _serial_read, it fails to sent the data back.

[0xc0170]

@TaniaMirzin Is this issue still valid? The referenced jira issue seems to be closed and there has been no progress here. Shall we close?

[TaniaMirzin]

@0xc0170 Yes.Thank you.