Corrupted data when stopping and starting the Serial Monitor during transmission

1

I’m using VS Code with 3.1.1 release of PlatformIO IDE. Here are my settings:

[env:esp32doit-devkit-v1]
platform = espressif32
board = esp32doit-devkit-v1
framework = arduino
monitor_speed = 115200
monitor_rts = 0
monitor_dtr = 0
build_unflags = -std=gnu++11
build_flags = -std=gnu++2a
lib_deps = 
  knolleary/PubSubClient@^2.8
  mikalhart/Streaming@^1.0.0

The test program:

#include <Arduino.h>
#include <Streaming.h>

void setup() {
  delay(1000);
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
}

void loop() {
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));              
  delay(500);
  Serial << "blah\n";
  Serial.flush();  
}

Serial monitor displays good data when I start it before rebooting ESP32 board. Stop/Start Monitoring sequence produces corrupt data most of the time and occasionally freezes the program on ESP32 board. Here is an example of “normal” corrupted data followed by a case, which froze the program on ESP32:

---- Closed the serial port /dev/ttyACM0 ----
---- Opened the serial port /dev/ttyACM0 ----
�'� #��'�`#��'� b�
---- Closed the serial port /dev/ttyACM0 ----
---- Opened the serial port /dev/ttyACM0 ----
## $$$$$$d$$$d$$$d$$$$l$$$d$$$$$$$$l$$$d$$$$$$$$$$$$$$$$l$$$$$$$$l$$$$l$$$d$$$$l$$$d$$$$l$$$l$$$$$$$$l$$$$$$$$d$$$$$$$$l$$$d$$

Is there a solution to this problem? I’m testing a different device without convenient access to reboot or power cycling.

2

But no such issue exists when using

#include <Arduino.h>
void setup() {
  delay(1000);
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
}

void loop() {
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));              
  delay(500);
  Serial.print("blah\n");
  Serial.flush();  
}

? If yes, it may be a problem with the Streaming.h library.

3

No. That version behaves the same.

4

With these options deleted it’s still broken?

5

Yes, the same problem.

6

And also with just

[env:esp32doit-devkit-v1]
platform = espressif32
board = esp32doit-devkit-v1
framework = arduino
monitor_speed = 115200

?

7

No change. I will try on a different OS/PC later today.

8

On some Linux distributions, certain installed programmes like brltty or modem manager can also interfere with serial ports. Make sure they’re removed (some come auto-installed with the distribution).

9

Yes. I did reinstall udev.rules and removed modem manager, which wasn’t there, but brltty was:

paul@desktop:~$ curl -fsSL https://raw.githubusercontent.com/platformio/platformio-core/develop/platformio/assets/system/99-platformio-udev.rules | sudo tee /etc/udev/rules.d/99-platformio-udev.rules
paul@desktop:~$ sudo service udev restart
paul@desktop:~$ sudo apt purge modemmanager
paul@desktop:~$ sudo apt purge brltty

Unfortunately, no improvement.

10

I tested on Raspberry Pi with the most current OS and fresh installation of VSCode and PlatformIO. Behavior is essentially the same, except of a single instance of a corrupt stream turning into a valid one.

I also noticed that my Ubuntu setup has two serial monitors. I have VSCode extension for Arduino installed there, but disabled for these tests. Here is the PlatformIO being used:

Screenshot from 2023-05-07 13-57-49
Screenshot from 2023-05-07 13-57-491196×221 28.8 KB

Here is the remnant of Arduino being used:

Screenshot from 2023-05-07 13-58-30
Screenshot from 2023-05-07 13-58-301196×221 34.6 KB

Again, the behavior is the same. There is no Arduino extension for VSCode on Raspberry Pi.

11

I went for something completely different and repeated this test with Seeeduino Xiao SAMD. No problems at all with starting and stopping serial monitor, both with PlatformIO and Arduino. I will test a few other ESP32 boards. Perhaps the serial to USB chip on DOIT ESP32 DEV KIT v1 board, i.e. CH9201X, is causing the problem. I selected this chip, because it is supposed to automatically go to the low power state when USB is not being used.

12

I tested a few different ESP32 boards with QinHeng Electronics CH340 serial to USB chip. No problems with corrupted data. It seems that behavior of CH9201X (1a86:55d4 QinHeng Electronics USB Single Serial) is the source of this problem.

13

The voltage during stop and start is high and may have an impact.