ESP32 CDC print("0123" * 64) causes missing beginning of the string
Port, board and/or hardware
ESP32-S3-Box-3
MicroPython version
Tested on v1.24.0 and v1.25.0.
After built and CDC to the REPL:
>>> print("0123"*64)
23012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123
missing the beginning part of the string. The string happens to be 255 long. So if we print more, there will be missing more in the beginning.
also in C, functions like mp_printf are also affected. If the string from multiple mp_printf exceeds 255, the beginning would sometimes be missing as well.
Switching to JTAG solves the problem, also unix port doesn't have this problem.
Reproduction
- git clone from repo, pick a recent version that compiles.
- cd ports/esp32/ ; make BOARD=ESP32_GENERIC_S3 VARIANT=SPIRAM_OCT
- after flash, connect to device using
mpremote connect COM26 - with
>>>prompt, runprint("0123" * 64)
Expected behaviour
0123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123
Observed behaviour
23012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123012301230123
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
USB xmit of exactly 64 bytes stalls
Port, board and/or hardware
rp2, 2040
MicroPython version
current master, 17d82344581a
Reproduction
- Create a CDC port, as described by
micropython-lib/micropython/usb/usb-device-cdc/usb/device/cdc.py - Open it with your favorite terminal
cdc.write(b"X"*64)- observe that nothing happens
I have verified that this happens when I call usb.device.get()._usbd.submit_xfer(cdc.ep_d_in, b"X"*64) directly, so this is not a library problem.
Expected behaviour
Writes don't stall, regardless of their length. :-P
Observed behaviour
The data is buffered until the next write. A zero-length write flushes the buffer. Any other length works perfectly.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree