ARMmbed
webUSB: multiple characters need to be sent before we can reliably read back over serial
It would appear that using webUSB and serial we see corruption (or commonly nothing) for the first N bytes sent from target to interface, where N bytes seems to be determined by USBD_CDC_ACM_SENDBUF_SIZE, and we can see the bytes we 'missed' sent to a serial terminal when it's connected.
No serial device needs to be connected for this to happen.
It appears that until the CDC send buffer is full, there's a race (that the CDC polling thread usually wins) to read characters from the UART buffers. This means we don't see the data we expect on webUSB serial after a cold boot.
How to reproduce this (using micro:bit V2 as an example and python.microbit.org)
From a cold start (freshly plugged in), with MicroPython already on the board:
Click ‘open serial'
Choose the micro:bit
Then connect
Then focus the REPL and press ctrl+c
I get this or similarly lacklustre response
But if I perservere it ‘comes right'
And after that, it’s reliable and clear
A good way to try this is press ctrl+c, then type help()
- If I close and re-open serial after this, it works fine
- If I reset the target, it works fine
- if I unplug and replug the micro:bit, it breaks again until enough characters have been sent.
Depending on your DAPLink build, you will lose fewer or more characters.
GIven we don't think we have a reliable way of knowing cross-OS when a serial terminal is actually connected (ie @c1728p9 didn't seem to reliably see the port line state being set usefully on Windows) I am not sure how we can really arbitrate, except perhaps to say once webUSB has started polling the UART we redirect all traffic there (until... when?). This would still mean we lost characters sent before webUSB was connected, but would mitigate the issue for the Python Editor nicely.
