Arduino Nano ESP32 Freezes when PC writes on the serial

Official Hardware Nano Family Nano ESP32
1

[Updated]
Hello everyone,
As you can read in the title, my Arduino freezes when I try to post data through the serial. This problem is triggered after leaving arduino working for 2/3 days and to replicate the problem I just increase the write speed on the Serial. It seems that the serial buffer is not being cleared correctly. Does it something that I can check also somewhere?

I have checked if this problem is related to Arduino Nano ESP32 with Arduino in general. I have run the same code on an Arduino UNO and it does not crash when the PC publishes at high frequency.
Both Arduinos are connected through USB
Arduino Code:

/*
 * rosserial Publisher Example
 * Prints "hello world!"
 */

void setup()
{
  Serial.begin(115200);

  pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
  if (Serial.available() > 0) {
    int bytesRead = Serial.read();
    Serial.println(bytesRead);
  }
  delay(1);
}

Python Code

import serial
import time
import random

# Configure the serial port
serial_port = '/dev/ttyACM0'  
baud_rate = 115200  

# Initialize the serial connection
ser = serial.Serial(serial_port, baud_rate)

try:
    while True:
        
        val = random.randint(0, 1e10)
        
        value_str = str(val)
        
        ser.write(value_str.encode())
        
        time.sleep(0.001)
except KeyboardInterrupt:
    ser.close()

Thanks for your advise

2

I'm not too surprised. The UART buffer has its limits on any platform. Flush the UART buffer before it fills up, maybe?

You could try and work out where the problem originates; it might be associated with how the Arduino ESP core handles the UART, or it may be in a deeper layer. In principle, the ESP32 as such shouldn't lock up upon a buffer overflow.

Btw, note that your sketch introduces the additional challenge of UART TX as it's RX-ing. Does the ESP also lock up if you simply read and discard the data?

3

If If remove the Serial.println(bytesRead), the Arduino doesn't block any more but in the future I need to write and read on the serial at the same time.

4

Well, I'd start my removing the unnecessary 1ms delay in the ESP32's loop().
Maybe pace things a little slower on the python/PC side so that the ESP32 has time to keep up?

1 Like
5

The Arduino Nano ESP32's default USB implementation is based on TinyUSB to allow multiple features to be provided (in particular, the serial port and the firmware upload via DFU). Reading or writing lots of data via the emulated serial port can cause this situation.

You can try to use the hardware USB by enabling debug mode, but that makes updating trickier. Make sure you follow that document and understand the implications on the programming sequence.

6

Thanks for your reply, I will check for debug mode to see what the problem is. Also I updated the topic with more information

As you can read in the title, my Arduino freezes when I try to post data through the serial. This problem is triggered after leaving arduino working for 2/3 days and to replicate the problem I just increase the write speed on the Serial. It seems that the serial buffer is not being cleared correctly. Does it something that I can check also somewhere?

7

I've used debug mode on my Arduino Nano ESP32 and now it works. The big difference is that instead of using USBCDC, it used HWCDC for serial communication. I was looking for the difference but not able to find it.
Thanks in advance

2 Likes
8

A "CDC" is how the USB standard refers to a communication device - in our case, a serial port. This is usually implemented in software, using a piece of code that implements that standard.

A very nice feature of the ESP32-S3 is that it provides a native implementation of that baked in the CPU (the HWCDC), so you could have a working Serial-over-USB connection with almost no software effort. The downside with that is you cannot access the USB port directly anymore, so you're essentially locked to what is exposed by the hardware: a serial and a debug interface only.
Arduino chose to use the software USB to allow everyone to easily reflash the board via DFU and not mess with jumpers et al by default, at a slight performance/robustness cost.

1 Like