What is expected error rate and drop rate on ST-Link VCP USART?

Question

What is expected error rate and drop rate on ST-Link VCP USART?

On the Nucleo STM32F446RE, my code reads the USART VCP (of ST-Link) and echoes it back. It uses DMA, FreeRTOS, and FreeRTOS queues (enqueing each byte individually). It ISRs the DMA Transfer Complete, but also ISRs the USART IDLE, so that it echoes byte by byte.

When testing it manually, it seems to work perfectly.

I wanted to benchmark it, and found a linux-serial-test tool, which gives poor results:

$ linux-serial-test -p /dev/ttyACM0  -s  -n -f -Z -o 5 -i 7
    Linux serial test app
    Flush RX buffer.
    Stopped transmitting.
    /dev/ttyACM0: count for this session: rx=24764, tx=49152, rx err=12
    Stopped receiving.
    /dev/ttyACM0: count for this session: rx=27121, tx=49152, rx err=12

Nearly half the bytes dropped! And a non-trivial amount of errors. (Note that errors were much higher until I tweaked the DMA buffer size. And if I use the -w option, they go up also.)

Are these drops and errors hardware limits of the ST-Link (esp. since no flow control)? Are they potential issues in my code? Or perhaps the linux-serial-tester itself isn't testing correctly?

What performance of the VCP should I expect, and how should I test it?

---

Adding a delay in transmission (-a 1000) improves results:

$ linux-serial-test -p /dev/ttyACM0  -s  -n -f -Z -o 15 -i 25 -a 1000
Linux serial test app
Flush RX buffer.
/dev/ttyACM0: count for this session: rx=17977, tx=20480, rx err=0
/dev/ttyACM0: count for this session: rx=44060, tx=45056, rx err=0
Stopped transmitting.
/dev/ttyACM0: No data received for 2.0s. Exiting due to timeout.

and turning on compiler optimizations (either -Os or -O3) improves the rx rate while slightly increasing errors:

$ linux-serial-test -p /dev/ttyACM0  -s  -n -f -Z -o 5 -i 10
Linux serial test app
Flush RX buffer.
Stopped transmitting.
/dev/ttyACM0: count for this session: rx=36874, tx=53248, rx err=85
/dev/ttyACM0: No data received for 2.0s. Exiting due to timeout.

(the exact results vary, but that seems to be the pattern).

Answer 1

So I did a test.

Using your first command line, I tested three different serial ports.

1. Some FTDI 232R USB cable, shorted TX to RX, no problems, 55296/55296, err=0

2. Laptop built-in RS232 port with TX shorted to RX, no problems, 54031/54031, err=0

3. Nucleo H7 with onboard ST-Link FW V2J38M27 or V2J39M27, TX shorted to RX, problems, always first test shows less received than sent, e.g 65012/65536, err=0

4. Same Nucleo H7 with updated firmware to V2J42M27, even worse numbers and always first test fails, 61709/65536, err=0

But, this may mean nothing.

It may be the Nucleo FW is bad but we don't know. Linux ACM drivers may work poorly with STLink ACM. Test program may be arbitrary and may not be designed to take into account the specifics of some ports, like how USB fits into this, or ACM over USB, etc.

For example, it might just be that the ST-Link firmware has so small buffers that it can't receive all the data in the time required and send them to PC.

For example the FTDI 232R has 128 byte buffer on USB to UART transmit side, and 256 byte UART receive buffer to USB. So it can receive more than transmit in a single USB packet, but still it will lose data when receiving at 3Mbps, because 256 bytes handled as often as PC can poll the USB interface is less than continuous data stream at 3 Mbps.

So without flow control, there can anyway be missed bytes, depending on USB poll rate, USB packet size, and receive packet FIFO size in the USB UART chip implementation.

Since you noticed the issue, you could ask on ST forums if this is normal, what are the actual specs it can handle, and will there be ever be a fix or improvement, either on the firmware, specs, or documentation what the USB ACM VCP is capable of.