I have a M5StickC core and two M5StickC Plus cores and have been struggling with poor serial performance on the plus cores. When running at high bitrates the Plus modules often have corrupt data initially when viewed in the arduino serial monitor, while the older non plus module is stable. And more importantly when using processing to receive the serial data the connection is not stable, and processing often locks up or is unable to receive any data at all. Again the older M5StickC module runs perfectly without any issues. Currently I can't even get processing to connect at all to the Plus module and it always locks up when I try to open the port. I picked up a second plus and that worked sporadically for a few weeks but it too now no longer works.

Here is a link to some minimal test code that recreates the problem perfectly on my machine. This opens a serial port and sends out a message once a second, as well as blinking the internal led so we know the board is still alive.

https://drive.google.com/file/d/1kYFH_JvTj_K35B1hLpr68fPbGj3oHStv/view?usp=sharing

I'm running this on windows 10, using the arduino 1.8.19 ide, M5Stack Board library version 2.0.5+1.0, and processing 4.0.1. I'm using the default settings for a M5StickC or Plus board in the arduino ide. And finally I have tried a lot of serial bitrates from 300 to 500000 baud, and have experimented with targeting lower clock speeds on the board as well. All this is with a bare module with no hats installed.

So typically running the above code I can open the arduino serial monitor and see data coming through, often with the first line being corrupted with non ascii characters. However once I open the processing program I get no data and the blinking light stops. And finally if I close the processing program and open back up the serial monitor then I often don't receive data anymore on the arduino ide either.

On two occasions after doing the above sequence I got the following message from the serial monitor (again with nothing plugged into the hat interface). This indicates to me that the board has crashed or rebooted into reprogramming mode. Is it possible that the processing serial code is playing with the hardware flow control pins somehow?

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x0 (DOWNLOAD_BOOT(UART0/UART1/SDIO_FEI_FEO_V2))
waiting for download