arduino-esp32 Arduino IDE ESP32-C3 USB CDC problems

Board

ESP32-C3

Device Description

ESP32-C3-DevKitC-02

Hardware Configuration

D- attached to GPIO18, D+ attached to GPIO19

Version

latest master

IDE Name

Arduino IDE

Operating System

Windows 10

Flash frequency

80 MHz

PSRAM enabled

yes

Upload speed

921600

Description

The first issue is that the USBSerial example for ESP32C3 in the Arduino IDE absolutely does not work for the C3. It works for the S2, but the C3 is different. I managed to get it working on the C3, but it took a few days and it still has issues I can't solve.

With the sketch I included, one of the issues is that after a reset, the USB doesn't work on the first opening of the port. This can be visualized with the led on GPIO9. On reset, the led is on, but it should be off. When the COM port is opened, the led stays lit. When you then close the COM port you can see the led flash and go off. When the COM port is opened afterward, it works properly. COM port opened, led on; COM port closed, led off.

The major issue is that every time you first write to the USB port, it's somehow taking your written data and joining it after "ESP-ROM:esp32c3-api1-20210207\r\n", so you end up with "ESP-ROM:esp32c3-api1-20210207\r\n[YOUR DESIRED DATA]". This only happens on the first write after opening the USB port. This issue renders the ESP32C3 useless for my application, because it's main purpose is as a USB-UART bridge and that data I didn't ask for gets sent to the PC software, and the software then can't do it's job. There's no workaround for the software it's talking to because I don't control it. It needs to only be sending the data I tell it to. I would imagine anybody trying to use the ESP32C3 as a USB-UART bridge is also going to also see this as a problem.

Sketch

#include "USB.h"

uint8_t led = 9;
bool uart_enabled = false;

static void usbEventCallback(void* arg, esp_event_base_t event_base, int32_t event_id, void* event_data){
  if(event_base == ARDUINO_HW_CDC_EVENTS){
    arduino_hw_cdc_event_data_t * data = (arduino_hw_cdc_event_data_t*)event_data;
    switch (event_id){
      case ARDUINO_HW_CDC_CONNECTED_EVENT:
        usb_connected();
        break;
      /*case ARDUINO_HW_CDC_BUS_RESET_EVENT:
        // might be useful later
        break;*/
      case ARDUINO_HW_CDC_RX_EVENT:
        {
            uint8_t buf[data->rx.len];
            size_t len = Serial.read(buf, data->rx.len);
            Serial0.write(buf, len);
        }
        break;
       /*case ARDUINO_HW_CDC_TX_EVENT:
         // might be useful later
        break;*/
      
      default:
        break;
    }
  }
}

void setup() {
  //Serial0.setDebugOutput(true);
  //Serial.setDebugOutput(true);
  Serial.begin();
  Serial.onEvent(usbEventCallback);
  pinMode(led, OUTPUT);
  Serial0.begin(230400);
}

void loop() {
  while(Serial0.available()){
    size_t l = Serial0.available();
    uint8_t b[l];
    l = Serial0.read(b, l);
    Serial.write(b, l);
  }
}

void usb_connected(){
  uart_enabled = true;
  digitalWrite(led, HIGH);
}

Debug Message

Enabling or disabling debug messages makes no difference

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

[X] I confirm I have checked existing issues, online documentation and Troubleshooting guide.

Jan 01 '22 15:01 specternecter

Regarding the 2nd issue (that ROM sign-on message is printed every time you open the port) I think this could be solved by burning some of the eFuse bits. If memory serves, there are two related eFuses — UART_PRINT_CONTROL (which controls printing of ROM boot messages, both over UART and USB_SERIAL_JTAG) and USB_PRINT_CHANNEL (which controls whether ROM code will print boot messages to USB_SERIAL_JTAG). Probably burning one or both can help remove the ROM boot messages from USB_SERIAL_JTAG output.

Regarding the issue where you observe an LED state when opening the port — keep in mind that DTR and RTS signals of the USB CDC port provided by USB_SERIAL_JTAG actually control "reset" and "boot mode" signals of the ESP32-C3. The behavior is very similar to how DTR and RTS signals controlled EN and GPIO0 on ESP32 dev board via a pair of transistors. Depending on what the serial terminal program is doing with DTR/RTS signals, it might be putting ESP32-C3 into a state where it's not actually running your sketch — being either reset or in ROM download mode.

If you'd like to find out more, the information about eFuses and about USB_SERIAL_JTAG peripheral can be found in the ESP32-C3 TRM. Let me know if you end up having questions!

(The issue that the example sketch doesn't work on C3 out of the box is still something we should fix, though. Not sure whether by providing a C3-specific sketch, or making the original one compatible. I'll leave that question to my colleagues more familiar with USB!)

Jan 01 '22 20:01 igrr

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial calls including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that once the efuses are written they can't be changed, so I am not sure how to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

Feb 27 '22 18:02 kriswiner

I think the USB issues are in the bootloader itself or internal hardware. If you set an led to turn on at the very beginning of your setup function and have it delay 15 seconds before calling serial.begin() you'll see something odd. After the led stops, open the serial monitor. You'll get nothing. Now close it and open it again while the led is still on. When the led stops it'll all work. Now notice that when you close the monitor is when the esp32-c3 actually resets, not when you open it, like it should be. That's why I keep the led on for 15 seconds at the beginning. So I know when to open it if I want it to work. Also if you open the port with a different monitoring program such as realTerm you'll ALWAYS get that weird message at the beginning where it identifies itself, but again it experiences the same strange behavior as it does with arduino. I just don't think arduino's serial monitor is fast enough to always catch the identification message.

On Sun, Feb 27, 2022, 1:30 PM Kris Winer @.***> wrote:

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial call including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that one the efuses are written they can't be changed, so I am not sure hot to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053639702, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWTRKXIVK5Q4535AUZL46KLU5JUUZANCNFSM5LCTD6TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

Feb 27 '22 18:02 specternecter

I don't think this is a boot loader issue per se. I think it is what Igor was saying, something internal to the USB peripheral is requesting RTS/CTS or some other kind of handshake and this can only be satisfied when the serial monitor is open. When it is closed, these pending transactions stall the program. I don;t know how to clear this or turn off the transactions yet. SOmething for Espressif to help us manage I would think. But the ESP32 C3 Mini is basically useless with this limitation.

On Sun, Feb 27, 2022 at 10:51 AM specternecter @.***> wrote:

I think the USB issues are in the bootloader itself or internal hardware. If you set an led to turn on at the very beginning of your setup function and have it delay 15 seconds before calling serial.begin() you'll see something odd. After the led stops, open the serial monitor. You'll get nothing. Now close it and open it again while the led is still on. When the led stops it'll all work. Now notice that when you close the monitor is when the esp32-c3 actually resets, not when you open it, like it should be. That's why I keep the led on for 15 seconds at the beginning. So I know when to open it if I want it to work. Also if you open the port with a different monitoring program such as realTerm you'll ALWAYS get that weird message at the beginning where it identifies itself, but again it experiences the same strange behavior as it does with arduino. I just don't think arduino's serial monitor is fast enough to always catch the identification message.

On Sun, Feb 27, 2022, 1:30 PM Kris Winer @.***> wrote:

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial call including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that one the efuses are written they can't be changed, so I am not sure hot to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053639702 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AWTRKXIVK5Q4535AUZL46KLU5JUUZANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053644435, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVFSNFDILLZHUHNLKTU5JXEPANCNFSM5LCTD6TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

Feb 27 '22 18:02 kriswiner

Yeah I wasn't sure exactly what the problem was but I was pretty confident it's something on their side and figured out a way to work around it. Rather annoyingly.

On Sun, Feb 27, 2022, 1:58 PM Kris Winer @.***> wrote:

I don't think this is a boot loader issue per se. I think it is what Igor was saying, something internal to the USB peripheral is requesting RTS/CTS or some other kind of handshake and this can only be satisfied when the serial monitor is open. When it is closed, these pending transactions stall the program. I don;t know how to clear this or turn off the transactions yet. SOmething for Espressif to help us manage I would think. But the ESP32 C3 Mini is basically useless with this limitation.

On Sun, Feb 27, 2022 at 10:51 AM specternecter @.***> wrote:

I think the USB issues are in the bootloader itself or internal hardware. If you set an led to turn on at the very beginning of your setup function and have it delay 15 seconds before calling serial.begin() you'll see something odd. After the led stops, open the serial monitor. You'll get nothing. Now close it and open it again while the led is still on. When the led stops it'll all work. Now notice that when you close the monitor is when the esp32-c3 actually resets, not when you open it, like it should be. That's why I keep the led on for 15 seconds at the beginning. So I know when to open it if I want it to work. Also if you open the port with a different monitoring program such as realTerm you'll ALWAYS get that weird message at the beginning where it identifies itself, but again it experiences the same strange behavior as it does with arduino. I just don't think arduino's serial monitor is fast enough to always catch the identification message.

On Sun, Feb 27, 2022, 1:30 PM Kris Winer @.***> wrote:

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial call including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that one the efuses are written they can't be changed, so I am not sure hot to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053639702

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AWTRKXIVK5Q4535AUZL46KLU5JUUZANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053644435 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKVFSNFDILLZHUHNLKTU5JXEPANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646064, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWTRKXKPZM4JD6YBMWQGF23U5JX5LANCNFSM5LCTD6TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

Feb 27 '22 19:02 specternecter

Can you run your program with the serial monitor closed? The only work around I have found is either keep the serial monitor open (which is fine for program debugging) or, when using deep sleep to save power, I have to open and close the serial monitor after every wake up just to get the thing to run. Ridiculous. There must be a way to turn off the RTS/CTS or DTR/DTS (not sure which) handshaking under the hood to allow running a program without the serial monitor having to be open...

On Sun, Feb 27, 2022 at 11:01 AM specternecter @.***> wrote:

Yeah I wasn't sure exactly what the problem was but I was pretty confident it's something on their side and figured out a way to work around it. Rather annoyingly.

On Sun, Feb 27, 2022, 1:58 PM Kris Winer @.***> wrote:

I don't think this is a boot loader issue per se. I think it is what Igor was saying, something internal to the USB peripheral is requesting RTS/CTS or some other kind of handshake and this can only be satisfied when the serial monitor is open. When it is closed, these pending transactions stall the program. I don;t know how to clear this or turn off the transactions yet. SOmething for Espressif to help us manage I would think. But the ESP32 C3 Mini is basically useless with this limitation.

On Sun, Feb 27, 2022 at 10:51 AM specternecter @.***> wrote:

I think the USB issues are in the bootloader itself or internal hardware. If you set an led to turn on at the very beginning of your setup function and have it delay 15 seconds before calling serial.begin() you'll see something odd. After the led stops, open the serial monitor. You'll get nothing. Now close it and open it again while the led is still on. When the led stops it'll all work. Now notice that when you close the monitor is when the esp32-c3 actually resets, not when you open it, like it should be. That's why I keep the led on for 15 seconds at the beginning. So I know when to open it if I want it to work. Also if you open the port with a different monitoring program such as realTerm you'll ALWAYS get that weird message at the beginning where it identifies itself, but again it experiences the same strange behavior as it does with arduino. I just don't think arduino's serial monitor is fast enough to always catch the identification message.

On Sun, Feb 27, 2022, 1:30 PM Kris Winer @.***> wrote:

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial call including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that one the efuses are written they can't be changed, so I am not sure hot to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053639702

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AWTRKXIVK5Q4535AUZL46KLU5JUUZANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053644435

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKVFSNFDILLZHUHNLKTU5JXEPANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646064 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AWTRKXKPZM4JD6YBMWQGF23U5JX5LANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646693, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKTG3XONKH24WNWT4WDU5JYG3ANCNFSM5LCTD6TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

Feb 27 '22 19:02 kriswiner

Yes I can, but I'm also using an esp32-c3-wroom-02. I also experience the issue where it will sometimes run the sketch from the beginning but doesn't start led like it should. That's why I start by first opening and closing the monitor, and opening it again while the led is still on. Because if you don't open it while the led is still on you have that issue. It's almost like it's only doing a partial reset or something.

On Sun, Feb 27, 2022, 2:06 PM Kris Winer @.***> wrote:

Can you run your program with the serial monitor closed? The only work around I have found is either keep the serial monitor open (which is fine for program debugging) or, when using deep sleep to save power, I have to open and close the serial monitor after every wake up just to get the thing to run. Ridiculous. There must be a way to turn off the RTS/CTS or DTR/DTS (not sure which) handshaking under the hood to allow running a program without the serial monitor having to be open...

On Sun, Feb 27, 2022 at 11:01 AM specternecter @.***> wrote:

Yeah I wasn't sure exactly what the problem was but I was pretty confident it's something on their side and figured out a way to work around it. Rather annoyingly.

On Sun, Feb 27, 2022, 1:58 PM Kris Winer @.***> wrote:

I don't think this is a boot loader issue per se. I think it is what Igor was saying, something internal to the USB peripheral is requesting RTS/CTS or some other kind of handshake and this can only be satisfied when the serial monitor is open. When it is closed, these pending transactions stall the program. I don;t know how to clear this or turn off the transactions yet. SOmething for Espressif to help us manage I would think. But the ESP32 C3 Mini is basically useless with this limitation.

On Sun, Feb 27, 2022 at 10:51 AM specternecter @.***> wrote:

I think the USB issues are in the bootloader itself or internal hardware. If you set an led to turn on at the very beginning of your setup function and have it delay 15 seconds before calling serial.begin() you'll see something odd. After the led stops, open the serial monitor. You'll get nothing. Now close it and open it again while the led is still on. When the led stops it'll all work. Now notice that when you close the monitor is when the esp32-c3 actually resets, not when you open it, like it should be. That's why I keep the led on for 15 seconds at the beginning. So I know when to open it if I want it to work. Also if you open the port with a different monitoring program such as realTerm you'll ALWAYS get that weird message at the beginning where it identifies itself, but again it experiences the same strange behavior as it does with arduino. I just don't think arduino's serial monitor is fast enough to always catch the identification message.

On Sun, Feb 27, 2022, 1:30 PM Kris Winer @.***> wrote:

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial call including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that one the efuses are written they can't be changed, so I am not sure hot to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053639702

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AWTRKXIVK5Q4535AUZL46KLU5JUUZANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053644435

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKVFSNFDILLZHUHNLKTU5JXEPANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646064

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AWTRKXKPZM4JD6YBMWQGF23U5JX5LANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646693 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKTG3XONKH24WNWT4WDU5JYG3ANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053648331, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWTRKXIQUOGIWJSKCK3MAGDU5JY3FANCNFSM5LCTD6TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

Feb 27 '22 19:02 specternecter

Well, if you don't open it after first closing it I mean

On Sun, Feb 27, 2022, 2:13 PM Brad Bock @.***> wrote:

Yes I can, but I'm also using an esp32-c3-wroom-02. I also experience the issue where it will sometimes run the sketch from the beginning but doesn't start led like it should. That's why I start by first opening and closing the monitor, and opening it again while the led is still on. Because if you don't open it while the led is still on you have that issue. It's almost like it's only doing a partial reset or something.

On Sun, Feb 27, 2022, 2:06 PM Kris Winer @.***> wrote:

Can you run your program with the serial monitor closed? The only work around I have found is either keep the serial monitor open (which is fine for program debugging) or, when using deep sleep to save power, I have to open and close the serial monitor after every wake up just to get the thing to run. Ridiculous. There must be a way to turn off the RTS/CTS or DTR/DTS (not sure which) handshaking under the hood to allow running a program without the serial monitor having to be open...

On Sun, Feb 27, 2022 at 11:01 AM specternecter @.***> wrote:

Yeah I wasn't sure exactly what the problem was but I was pretty confident it's something on their side and figured out a way to work around it. Rather annoyingly.

On Sun, Feb 27, 2022, 1:58 PM Kris Winer @.***> wrote:

I don't think this is a boot loader issue per se. I think it is what Igor was saying, something internal to the USB peripheral is requesting RTS/CTS or some other kind of handshake and this can only be satisfied when the serial monitor is open. When it is closed, these pending transactions stall the program. I don;t know how to clear this or turn off the transactions yet. SOmething for Espressif to help us manage I would think. But the ESP32 C3 Mini is basically useless with this limitation.

On Sun, Feb 27, 2022 at 10:51 AM specternecter @.***> wrote:

I think the USB issues are in the bootloader itself or internal hardware. If you set an led to turn on at the very beginning of your setup function and have it delay 15 seconds before calling serial.begin() you'll see something odd. After the led stops, open the serial monitor. You'll get nothing. Now close it and open it again while the led is still on. When the led stops it'll all work. Now notice that when you close the monitor is when the esp32-c3 actually resets, not when you open it, like it should be. That's why I keep the led on for 15 seconds at the beginning. So I know when to open it if I want it to work. Also if you open the port with a different monitoring program such as realTerm you'll ALWAYS get that weird message at the beginning where it identifies itself, but again it experiences the same strange behavior as it does with arduino. I just don't think arduino's serial monitor is fast enough to always catch the identification message.

On Sun, Feb 27, 2022, 1:30 PM Kris Winer @.***> wrote:

Just want to say I see something similar with my Custom ESP32 C3 Mini dev board. I can program it via native USB (GPIO18/19) and get serial output on the monitor using USBSerial.begin, etc. However, the program won't run unless there is a serial monitor open, which is odd. I tried commenting out all USBSerial call including begin but there is something keeping the USB peripheral alive even when the USB connector itself is not connected (i.e, the device is running from battery). So something like the RTS/CTS handshake mentioned above is stalling the program and it will only resume when a serial monitor is opened.

I took a look at the TRM but it says there that one the efuses are written they can't be changed, so I am not sure hot to properly configure the USB UART to get reasonable behavior here. It would be useful if one could choose the behavior of USB UART in the tools menu of the Arduino IDE, like disable RTS/CTS, for example. Any advice?

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053639702

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AWTRKXIVK5Q4535AUZL46KLU5JUUZANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053644435

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/ABTDLKVFSNFDILLZHUHNLKTU5JXEPANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub <

https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646064

, or unsubscribe <

https://github.com/notifications/unsubscribe-auth/AWTRKXKPZM4JD6YBMWQGF23U5JX5LANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS <

https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android <

https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

.

You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053646693 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKTG3XONKH24WNWT4WDU5JYG3ANCNFSM5LCTD6TA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1053648331, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWTRKXIQUOGIWJSKCK3MAGDU5JY3FANCNFSM5LCTD6TA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

Feb 27 '22 19:02 specternecter

I can confirm that while some sketches may work with USB CDC enabled and without the COM port open, very few of them work properly. I ran into the problem when having 2 ESP32C3s communicate over LoRa. If you call Serial.begin() they barely communicate at all, let alone correctly, UNLESS the COM ports are open. If the COM ports are both open they work perfectly fine. If you want them to work without the COM ports open, you have to comment out Serial.begin(). I ran many different tests to see if it was just the SX1276 or if it was the USB CDC. It is definitely the USB CDC. Most sketches will have one bug or another unless the COM port is open or unless you never call Serial.begin(). Basically, it'll work fine but you can only call Serial.begin() if you plan on actively using it.

Mar 20 '22 01:03 specternecter

Hi @specternecter I am now testing your issue. Firstly I looked in docs and find out this about GPIO 9 that you are using for the LED. GPIO 2, 8 and 9 are strapping pins.

GPIO2, GPIO8, and GPIO9 are strapping pins of the ESP32-C3 chip. These pins are used to control several chip functions depending on binary voltage values applied to the pins during chip power-up or system reset. For description and application of the strapping pins, please refer to Section Strapping Pins in ESP32-C3 Datasheet.

By default, GPIO9 is connected to the internal weak pull-up resistor. If GPIO9 is not connected or connected to an external high-impedance circuit, the latched bit value will be ”1”

Can you try to change the LED pin to another free pin and test that out again. Thats first thing I found out. I am going to go more deeply and test everything to be sure its working. Will appreciate your collaboration.

Mar 22 '22 11:03 P-R-O-C-H-Y

I changed led to 8 and still have the issue

On Tue, Mar 22, 2022, 7:33 AM Jan Procházka @.***> wrote:

Hi @specternecter https://github.com/specternecter I am now testing your issue. Firstly I looked in docs and find out this about GPIO 9 that you are using for the LED. GPIO 0, 8 and 9 are strapping pins.

By default, GPIO9 is connected to the internal weak pull-up resistor. If GPIO9 is not connected or connected to an external high-impedance circuit, the latched bit value will be ”1”

Can you try to change the LED pin to another free pin and test that out again. Thats first thing I found out. I am going to go more deeply and test everything to be sure its working. Will appreciate your collaboration.

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1075065792, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWTRKXIAPUPO3UZBGG3BPR3VBGVXPANCNFSM5LCTD6TA . You are receiving this because you were mentioned.Message ID: @.***>

Mar 22 '22 15:03 specternecter

I think this behavior with the native USB has something to do with the fuse settings, which are not accessible as far as I know through the Arduino IDE. Igor mentioned this above but I have no idea what to do about it...

On Tue, Mar 22, 2022 at 8:37 AM specternecter @.***> wrote:

I changed led to 8 and still have the issue

On Tue, Mar 22, 2022, 7:33 AM Jan Procházka @.***> wrote:

Hi @specternecter https://github.com/specternecter I am now testing your issue. Firstly I looked in docs and find out this about GPIO 9 that you are using for the LED. GPIO 0, 8 and 9 are strapping pins.

By default, GPIO9 is connected to the internal weak pull-up resistor. If GPIO9 is not connected or connected to an external high-impedance circuit, the latched bit value will be ”1”

Can you try to change the LED pin to another free pin and test that out again. Thats first thing I found out. I am going to go more deeply and test everything to be sure its working. Will appreciate your collaboration.

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1075065792 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AWTRKXIAPUPO3UZBGG3BPR3VBGVXPANCNFSM5LCTD6TA

. You are receiving this because you were mentioned.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1075335651, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVOEMLMKK3EYKQPKGTVBHSLDANCNFSM5LCTD6TA . You are receiving this because you commented.Message ID: @.***>

Mar 22 '22 15:03 kriswiner

First thing I found out with my colleague is that there are no problems on MacOS. Seems to be windows specific. Have anyone option to test on Linux to be sure it's only happening on Windows?

There is simple Sketch to test the issue.

Sketch settings: USB-CDC on boot : DISABLED

#include <Arduino.h>

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

  for (uint8_t n = 0;; n++) {
    Serial.printf("UART-OK[%d] ", n);
    USBSerial.printf("USB-OK[%d] ", n);
    delay(500);
    if (!(n&0x7)){
      Serial.println();
      USBSerial.println();
    }
  }
}

void loop() {
}

The sketch prints a counting to the UART and CDC at the same time. Messages start with UART-OK[number] or USB-OK[number].

To demonstrate the RESET when CDC window is closed, you just need to open 2 windows, one for the UART port and another for the CDC port.
You will see both outputs with its correct labels and same counting sequence.
Then close the CDC window and you will see the RESET in the UART output happening.

Please test this and comment with results, if the chip is restarting.

On MACOS it is still counting - NO restart.

Mar 24 '22 13:03 P-R-O-C-H-Y

Is this test sketch supposed to work on a device with only native USB and no CP2102 or FTDI USB-to-UART transceiver?

On Thu, Mar 24, 2022 at 6:06 AM Jan Procházka @.***> wrote:

First thing I found out with my colleague is that there are no problems on MacOS. Seems to be windows specific. Have anyone option to test on Linux to be sure it's only happening on Windows?

There is simple Sketch to test the issue.

Sketch settings: USB-CDC on boot : DISABLED

#include <Arduino.h>

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

for (uint8_t n = 0;; n++) { Serial.printf("UART-OK[%d] ", n); USBSerial.printf("USB-OK[%d] ", n); delay(500); if (!(n&0x7)){ Serial.println(); USBSerial.println(); } } }

void loop() { }

The sketch prints a counting to the UART and CDC at the same time. Messages start with UART-OK[number] or USB-OK[number].

To demonstrate the RESET when CDC window is closed, you just need to open 2 windows, one for the UART port and another for the CDC port.

You will see both outputs with its correct labels and same counting sequence.

Then close the CDC window and you will see the RESET in the UART output happening.

Please test this and comment with results, if the chip is restarting.

On MACOS it is still counting - NO restart.

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1077607496, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUR4WGWX3PR3YA47YLVBRSGLANCNFSM5LCTD6TA . You are receiving this because you commented.Message ID: @.***>

Mar 24 '22 15:03 kriswiner

That test sketch was meant to test them both but the issue happens with or without uart0. And honestly you're opening a whole new can of worms with usb cdc on linux. I tried it about the same time as creating this issue and it had even more bugs than windows. It was honestly a massive headache so I decided to focus on windows considering over 80% of arduino users are on that platform. MacOS may be fine but I don't think it's a windows issue. I think it's just that maybe espressif happened to be working with a macOS when they developed this

On Thu, Mar 24, 2022, 11:58 AM Kris Winer @.***> wrote:

Is this test sketch supposed to work on a device with only native USB and no CP2102 or FTDI USB-to-UART transceiver?

On Thu, Mar 24, 2022 at 6:06 AM Jan Procházka @.***> wrote:

First thing I found out with my colleague is that there are no problems on MacOS. Seems to be windows specific. Have anyone option to test on Linux to be sure it's only happening on Windows?

There is simple Sketch to test the issue.

Sketch settings: USB-CDC on boot : DISABLED

#include <Arduino.h>

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

for (uint8_t n = 0;; n++) { Serial.printf("UART-OK[%d] ", n); USBSerial.printf("USB-OK[%d] ", n); delay(500); if (!(n&0x7)){ Serial.println(); USBSerial.println(); } } }

void loop() { }

The sketch prints a counting to the UART and CDC at the same time. Messages start with UART-OK[number] or USB-OK[number].

To demonstrate the RESET when CDC window is closed, you just need to open 2 windows, one for the UART port and another for the CDC port.

You will see both outputs with its correct labels and same counting sequence.

Then close the CDC window and you will see the RESET in the UART output happening.

Please test this and comment with results, if the chip is restarting.

On MACOS it is still counting - NO restart.

— Reply to this email directly, view it on GitHub < https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1077607496 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABTDLKUR4WGWX3PR3YA47YLVBRSGLANCNFSM5LCTD6TA

. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1077784148, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWTRKXLW4AEQLICIHJUFSB3VBSGJXANCNFSM5LCTD6TA . You are receiving this because you were mentioned.Message ID: @.***>

Mar 24 '22 21:03 specternecter

Is this test sketch supposed to work on a device with only native USB and no CP2102 or FTDI USB-to-UART transceiver? …

To test that connect simple USB cable (without trancievers) to ESP32C3 pins: D- to GPIO18, D+ to GPIO19, 5V and GND. And it should work as is.

Mar 25 '22 09:03 P-R-O-C-H-Y

I ran the sketch on my ESP32C3 device which uses the native USB only (no CP2102 transceiver). I see only a single COM port and get this output:

11:10:59.776 -> I (104) boot: 4 spiffs Unknown data 01 82 0029000USB-OK[0] 11:10:59.776 -> USB-OK[1] USB-OK[2] USB-OK[3] USB-OK[4] USB-OK[5] USB-OK[6] USB-OK[7] USB-OK[8] 11:10:59.776 -> USB-OK[9] USB-OK[10] USB-OK[11] USB-OK[12] USB-OK[13] USB-OK[14] USB-OK[15] USB-OK[16] 11:11:01.242 -> USB-OK[17] USB-OK[18] USB-OK[19] USB-OK[20] USB-OK[21] USB-OK[22] USB-OK[23] USB-OK[24] 11:11:05.238 -> USB-OK[25] USB-OK[26] USB-OK[27] USB-OK[28] USB-OK[29] USB-OK[30] USB-OK[31] USB-OK[32] 11:11:09.229 -> USB-OK[33] USB-OK[34] USB-OK[35] USB-OK[36] USB-OK[37] USB-OK[38] USB-OK[39] USB-OK[40] 11:11:13.270 -> USB-OK[41] USB-OK[42] USB-OK[43] USB-OK[44] USB-OK[45] USB-OK[46] USB-OK[47] USB-OK[48] 11:11:17.265 -> USB-OK[49] USB-OK[50] USB-OK[51] USB-OK[52] USB-OK[53] USB-OK[54] USB-OK[55] USB-OK[56] 11:11:21.226 -> USB-OK[57] USB-OK[58] USB-OK[59] USB-OK[60] USB-OK[61] USB-OK[62] USB-OK[63] USB-OK[64] 11:11:25.267 -> USB-OK[65] USB-OK[66] USB-OK[67] USB-OK[68] USB-OK[69] USB-OK[70] USB-OK[71] USB-OK[72] 11:11:29.248 -> USB-OK[73] USB-OK[74] USB-OK[75] USB-OK[76] USB-OK[77] USB-OK[78] USB-OK[79] USB-OK[80] 11:11:33.235 -> USB-OK[81] USB-OK[82] USB-OK[83] USB-OK[84] USB-OK[85] USB-OK[86] USB-OK[87] USB-OK[88] 11:11:37.267 -> USB-OK[89] USB-OK[90] USB-OK[91] USB-OK[92] USB-OK[93] USB-OK[94] USB-OK[95] USB-OK[96] 11:11:41.253 -> USB-OK[97] USB-OK[98] USB-OK[99] USB-OK[100] USB-OK[101] USB-OK[102] USB-OK[103] USB-OK[104] 11:11:45.246 -> USB-OK[105] USB-OK[106] USB-OK[107] USB-OK[108] USB-OK[109] USB-OK[110] USB-OK[111] USB-OK[112] 11:11:49.229 -> USB-OK[113] USB-OK[114] USB-OK[115] USB-OK[116] USB-OK[117] USB-OK[118] USB-OK[119] USB-OK[120] 11:11:53.264 -> USB-OK[121] USB-OK[122] USB-OK[123] USB-OK[124] USB-OK[125] USB-OK[126] USB-OK[127] USB-OK[128] 11:11:57.244 -> USB-OK[129] USB-OK[130] USB-OK[131] USB-OK[132] USB-OK[133] USB-OK[134] USB-OK[135] USB-OK[136] 11:12:01.231 -> USB-OK[137] USB-OK[138] USB-OK[139] USB-OK[140] USB-OK[141] USB-OK[142] USB-OK[143] USB-OK[144] 11:12:05.238 -> USB-OK[145] USB-OK[146] USB-OK[147] USB-OK[148] USB-OK[149] USB-OK[150] USB-OK[151] USB-OK[152] 11:12:09.226 -> USB-OK[153] USB-OK[154] USB-OK[155] USB-OK[156] USB-OK[157] USB-OK[158] USB-OK[159] USB-OK[160] 11:12:13.260 -> USB-OK[161] USB-OK[162] USB-OK[163] USB-OK[164] USB-OK[165] USB-OK[166] USB-OK[167] USB-OK[168] 11:12:17.236 -> USB-OK[169] USB-OK[170] USB-OK[171] USB-OK[172] USB-OK[173] USB-OK[174] USB-OK[175] USB-OK[176] 11:12:21.265 -> USB-OK[177] USB-OK[178] USB-OK[179] USB-OK[180]

Not sure what I am supposed to see happen; I don't have another COM port listed on the Arduino IDE to look at.

I added an led blink to the sketch and verified (somewhat to my surprise) that it continues to work when running off of just LiPo battery (so no USB connected).

Then I removed the USB.h define from my usual blink sketch and it also works now without the USB connected (by battery). So this USB.h call might have been messing up the C3 behavior somehow. I will try my deep sleep sketch next to see if this runs as expected too.

On Fri, Mar 25, 2022 at 2:15 AM Jan Procházka @.***> wrote:

Is this test sketch supposed to work on a device with only native USB and no CP2102 or FTDI USB-to-UART transceiver? … <#m_1937417918318087745_>

To test that connect simple USB cable (without trancievers) to ESP32C3 pins: D- to GPIO18, D+ to GPIO19, 5V and GND. And it should work as is.

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1078811103, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQME6Z2L6CA3C3SXN3VBV7ZVANCNFSM5LCTD6TA . You are receiving this because you commented.Message ID: @.***>

Mar 25 '22 18:03 kriswiner

I have the same problem I had before when using deep sleep. When the ESP32C3 wakes up it hangs until I open a serial monitor. If I try to run the sketch from battery it also hangs, presumably waiting for a serial monitor...

On Fri, Mar 25, 2022 at 11:26 AM Tlera Corporation @.***> wrote:

I ran the sketch on my ESP32C3 device which uses the native USB only (no CP2102 transceiver). I see only a single COM port and get this output:

11:10:59.776 -> I (104) boot: 4 spiffs Unknown data 01 82 0029000USB-OK[0] 11:10:59.776 -> USB-OK[1] USB-OK[2] USB-OK[3] USB-OK[4] USB-OK[5] USB-OK[6] USB-OK[7] USB-OK[8] 11:10:59.776 -> USB-OK[9] USB-OK[10] USB-OK[11] USB-OK[12] USB-OK[13] USB-OK[14] USB-OK[15] USB-OK[16] 11:11:01.242 -> USB-OK[17] USB-OK[18] USB-OK[19] USB-OK[20] USB-OK[21] USB-OK[22] USB-OK[23] USB-OK[24] 11:11:05.238 -> USB-OK[25] USB-OK[26] USB-OK[27] USB-OK[28] USB-OK[29] USB-OK[30] USB-OK[31] USB-OK[32] 11:11:09.229 -> USB-OK[33] USB-OK[34] USB-OK[35] USB-OK[36] USB-OK[37] USB-OK[38] USB-OK[39] USB-OK[40] 11:11:13.270 -> USB-OK[41] USB-OK[42] USB-OK[43] USB-OK[44] USB-OK[45] USB-OK[46] USB-OK[47] USB-OK[48] 11:11:17.265 -> USB-OK[49] USB-OK[50] USB-OK[51] USB-OK[52] USB-OK[53] USB-OK[54] USB-OK[55] USB-OK[56] 11:11:21.226 -> USB-OK[57] USB-OK[58] USB-OK[59] USB-OK[60] USB-OK[61] USB-OK[62] USB-OK[63] USB-OK[64] 11:11:25.267 -> USB-OK[65] USB-OK[66] USB-OK[67] USB-OK[68] USB-OK[69] USB-OK[70] USB-OK[71] USB-OK[72] 11:11:29.248 -> USB-OK[73] USB-OK[74] USB-OK[75] USB-OK[76] USB-OK[77] USB-OK[78] USB-OK[79] USB-OK[80] 11:11:33.235 -> USB-OK[81] USB-OK[82] USB-OK[83] USB-OK[84] USB-OK[85] USB-OK[86] USB-OK[87] USB-OK[88] 11:11:37.267 -> USB-OK[89] USB-OK[90] USB-OK[91] USB-OK[92] USB-OK[93] USB-OK[94] USB-OK[95] USB-OK[96] 11:11:41.253 -> USB-OK[97] USB-OK[98] USB-OK[99] USB-OK[100] USB-OK[101] USB-OK[102] USB-OK[103] USB-OK[104] 11:11:45.246 -> USB-OK[105] USB-OK[106] USB-OK[107] USB-OK[108] USB-OK[109] USB-OK[110] USB-OK[111] USB-OK[112] 11:11:49.229 -> USB-OK[113] USB-OK[114] USB-OK[115] USB-OK[116] USB-OK[117] USB-OK[118] USB-OK[119] USB-OK[120] 11:11:53.264 -> USB-OK[121] USB-OK[122] USB-OK[123] USB-OK[124] USB-OK[125] USB-OK[126] USB-OK[127] USB-OK[128] 11:11:57.244 -> USB-OK[129] USB-OK[130] USB-OK[131] USB-OK[132] USB-OK[133] USB-OK[134] USB-OK[135] USB-OK[136] 11:12:01.231 -> USB-OK[137] USB-OK[138] USB-OK[139] USB-OK[140] USB-OK[141] USB-OK[142] USB-OK[143] USB-OK[144] 11:12:05.238 -> USB-OK[145] USB-OK[146] USB-OK[147] USB-OK[148] USB-OK[149] USB-OK[150] USB-OK[151] USB-OK[152] 11:12:09.226 -> USB-OK[153] USB-OK[154] USB-OK[155] USB-OK[156] USB-OK[157] USB-OK[158] USB-OK[159] USB-OK[160] 11:12:13.260 -> USB-OK[161] USB-OK[162] USB-OK[163] USB-OK[164] USB-OK[165] USB-OK[166] USB-OK[167] USB-OK[168] 11:12:17.236 -> USB-OK[169] USB-OK[170] USB-OK[171] USB-OK[172] USB-OK[173] USB-OK[174] USB-OK[175] USB-OK[176] 11:12:21.265 -> USB-OK[177] USB-OK[178] USB-OK[179] USB-OK[180]

Not sure what I am supposed to see happen; I don't have another COM port listed on the Arduino IDE to look at.

I added an led blink to the sketch and verified (somewhat to my surprise) that it continues to work when running off of just LiPo battery (so no USB connected).

Then I removed the USB.h define from my usual blink sketch and it also works now without the USB connected (by battery). So this USB.h call might have been messing up the C3 behavior somehow. I will try my deep sleep sketch next to see if this runs as expected too.

On Fri, Mar 25, 2022 at 2:15 AM Jan Procházka @.***> wrote:

Is this test sketch supposed to work on a device with only native USB and no CP2102 or FTDI USB-to-UART transceiver? … <#m_7375461408396152391_m_1937417918318087745_>

To test that connect simple USB cable (without trancievers) to ESP32C3 pins: D- to GPIO18, D+ to GPIO19, 5V and GND. And it should work as is.

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1078811103, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQME6Z2L6CA3C3SXN3VBV7ZVANCNFSM5LCTD6TA . You are receiving this because you commented.Message ID: @.***>

Mar 25 '22 18:03 kriswiner

OK, maybe this is obvious, but when I removed all USBSerial calls like USBSerial.print, etc the sketch runs even using deep sleep. So I will be able to measure the power consumed. This is useful for building an environmental data logger, which is my goal. So now I can run the ESP32C3 using deep sleep mode and log data at whatever duty cycle I like and can calculate the battery lifetime, etc.

In the end, this is not such a surprising result since if I make a call to Serial.begin and wake from deep sleep apparently the ESP32 requires that I open a serial monitor to continue. Not sure why. But eliminating all of the Serial calls avoids this particular problem. On the STM32, for example, entering STOP mode also severs the serial monitor connection, but this only stop printing going to the serial monitor, otherwise the program continues to run when waking from STOP. On the ESP32C3, if I wake from deepSleep and don;t re-open the serial monitor, the program stops. Not very useful.

On Fri, Mar 25, 2022 at 11:37 AM Tlera Corporation @.***> wrote:

I have the same problem I had before when using deep sleep. When the ESP32C3 wakes up it hangs until I open a serial monitor. If I try to run the sketch from battery it also hangs, presumably waiting for a serial monitor...

On Fri, Mar 25, 2022 at 11:26 AM Tlera Corporation @.***> wrote:

I ran the sketch on my ESP32C3 device which uses the native USB only (no CP2102 transceiver). I see only a single COM port and get this output:

11:10:59.776 -> I (104) boot: 4 spiffs Unknown data 01 82 0029000USB-OK[0] 11:10:59.776 -> USB-OK[1] USB-OK[2] USB-OK[3] USB-OK[4] USB-OK[5] USB-OK[6] USB-OK[7] USB-OK[8] 11:10:59.776 -> USB-OK[9] USB-OK[10] USB-OK[11] USB-OK[12] USB-OK[13] USB-OK[14] USB-OK[15] USB-OK[16] 11:11:01.242 -> USB-OK[17] USB-OK[18] USB-OK[19] USB-OK[20] USB-OK[21] USB-OK[22] USB-OK[23] USB-OK[24] 11:11:05.238 -> USB-OK[25] USB-OK[26] USB-OK[27] USB-OK[28] USB-OK[29] USB-OK[30] USB-OK[31] USB-OK[32] 11:11:09.229 -> USB-OK[33] USB-OK[34] USB-OK[35] USB-OK[36] USB-OK[37] USB-OK[38] USB-OK[39] USB-OK[40] 11:11:13.270 -> USB-OK[41] USB-OK[42] USB-OK[43] USB-OK[44] USB-OK[45] USB-OK[46] USB-OK[47] USB-OK[48] 11:11:17.265 -> USB-OK[49] USB-OK[50] USB-OK[51] USB-OK[52] USB-OK[53] USB-OK[54] USB-OK[55] USB-OK[56] 11:11:21.226 -> USB-OK[57] USB-OK[58] USB-OK[59] USB-OK[60] USB-OK[61] USB-OK[62] USB-OK[63] USB-OK[64] 11:11:25.267 -> USB-OK[65] USB-OK[66] USB-OK[67] USB-OK[68] USB-OK[69] USB-OK[70] USB-OK[71] USB-OK[72] 11:11:29.248 -> USB-OK[73] USB-OK[74] USB-OK[75] USB-OK[76] USB-OK[77] USB-OK[78] USB-OK[79] USB-OK[80] 11:11:33.235 -> USB-OK[81] USB-OK[82] USB-OK[83] USB-OK[84] USB-OK[85] USB-OK[86] USB-OK[87] USB-OK[88] 11:11:37.267 -> USB-OK[89] USB-OK[90] USB-OK[91] USB-OK[92] USB-OK[93] USB-OK[94] USB-OK[95] USB-OK[96] 11:11:41.253 -> USB-OK[97] USB-OK[98] USB-OK[99] USB-OK[100] USB-OK[101] USB-OK[102] USB-OK[103] USB-OK[104] 11:11:45.246 -> USB-OK[105] USB-OK[106] USB-OK[107] USB-OK[108] USB-OK[109] USB-OK[110] USB-OK[111] USB-OK[112] 11:11:49.229 -> USB-OK[113] USB-OK[114] USB-OK[115] USB-OK[116] USB-OK[117] USB-OK[118] USB-OK[119] USB-OK[120] 11:11:53.264 -> USB-OK[121] USB-OK[122] USB-OK[123] USB-OK[124] USB-OK[125] USB-OK[126] USB-OK[127] USB-OK[128] 11:11:57.244 -> USB-OK[129] USB-OK[130] USB-OK[131] USB-OK[132] USB-OK[133] USB-OK[134] USB-OK[135] USB-OK[136] 11:12:01.231 -> USB-OK[137] USB-OK[138] USB-OK[139] USB-OK[140] USB-OK[141] USB-OK[142] USB-OK[143] USB-OK[144] 11:12:05.238 -> USB-OK[145] USB-OK[146] USB-OK[147] USB-OK[148] USB-OK[149] USB-OK[150] USB-OK[151] USB-OK[152] 11:12:09.226 -> USB-OK[153] USB-OK[154] USB-OK[155] USB-OK[156] USB-OK[157] USB-OK[158] USB-OK[159] USB-OK[160] 11:12:13.260 -> USB-OK[161] USB-OK[162] USB-OK[163] USB-OK[164] USB-OK[165] USB-OK[166] USB-OK[167] USB-OK[168] 11:12:17.236 -> USB-OK[169] USB-OK[170] USB-OK[171] USB-OK[172] USB-OK[173] USB-OK[174] USB-OK[175] USB-OK[176] 11:12:21.265 -> USB-OK[177] USB-OK[178] USB-OK[179] USB-OK[180]

Not sure what I am supposed to see happen; I don't have another COM port listed on the Arduino IDE to look at.

I added an led blink to the sketch and verified (somewhat to my surprise) that it continues to work when running off of just LiPo battery (so no USB connected).

Then I removed the USB.h define from my usual blink sketch and it also works now without the USB connected (by battery). So this USB.h call might have been messing up the C3 behavior somehow. I will try my deep sleep sketch next to see if this runs as expected too.

On Fri, Mar 25, 2022 at 2:15 AM Jan Procházka @.***> wrote:

Is this test sketch supposed to work on a device with only native USB and no CP2102 or FTDI USB-to-UART transceiver? … <#m_5054730352819127763_m_7375461408396152391_m_1937417918318087745_>

To test that connect simple USB cable (without trancievers) to ESP32C3 pins: D- to GPIO18, D+ to GPIO19, 5V and GND. And it should work as is.

— Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/6089#issuecomment-1078811103, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQME6Z2L6CA3C3SXN3VBV7ZVANCNFSM5LCTD6TA . You are receiving this because you commented.Message ID: @.***>

Mar 25 '22 18:03 kriswiner

I ran the sketch on my ESP32C3 device which uses the native USB only (no CP2102 transceiver). I see only a single COM port and get this output: 11:10:59.776 -> I (104) boot: 4 spiffs Unknown data 01 82 0029000USB-OK[0] 11:10:59.776 -> USB-OK[1] USB-OK[2] USB-OK[3] USB-OK[4] USB-OK[5] USB-OK[6] USB-OK[7] USB-OK[8] 11:10:59.776 -> USB-OK[9] USB-OK[10] USB-OK[11] USB-OK[12] USB-OK[13] USB-OK[14] USB-OK[15] USB-OK[16] 11:11:01.242 -> USB-OK[17] USB-OK[18] USB-OK[19] USB-OK[20] USB-OK[21] USB-OK[22] USB-OK[23] USB-OK[24] 11:11:05.238 -> USB-OK[25] USB-OK[26] USB-OK[27] USB-OK[28] USB-OK[29] USB-OK[30] USB-OK[31] USB-OK[32] 11:11:09.229 -> USB-OK[33] USB-OK[34] USB-OK[35] USB-OK[36] USB-OK[37] USB-OK[38] USB-OK[39] USB-OK[40] 11:11:13.270 -> USB-OK[41] USB-OK[42] USB-OK[43] USB-OK[44] USB-OK[45] USB-OK[46] USB-OK[47] USB-OK[48] 11:11:17.265 -> USB-OK[49] USB-OK[50] USB-OK[51] USB-OK[52] USB-OK[53] USB-OK[54] USB-OK[55] USB-OK[56] 11:11:21.226 -> USB-OK[57] USB-OK[58] USB-OK[59] USB-OK[60] USB-OK[61] USB-OK[62] USB-OK[63] USB-OK[64] 11:11:25.267 -> USB-OK[65] USB-OK[66] USB-OK[67] USB-OK[68] USB-OK[69] USB-OK[70] USB-OK[71] USB-OK[72] 11:11:29.248 -> USB-OK[73] USB-OK[74] USB-OK[75] USB-OK[76] USB-OK[77] USB-OK[78] USB-OK[79] USB-OK[80] 11:11:33.235 -> USB-OK[81] USB-OK[82] USB-OK[83] USB-OK[84] USB-OK[85] USB-OK[86] USB-OK[87] USB-OK[88] 11:11:37.267 -> USB-OK[89] USB-OK[90] USB-OK[91] USB-OK[92] USB-OK[93] USB-OK[94] USB-OK[95] USB-OK[96] 11:11:41.253 -> USB-OK[97] USB-OK[98] USB-OK[99] USB-OK[100] USB-OK[101] USB-OK[102] USB-OK[103] USB-OK[104] 11:11:45.246 -> USB-OK[105] USB-OK[106] USB-OK[107] USB-OK[108] USB-OK[109] USB-OK[110] USB-OK[111] USB-OK[112] 11:11:49.229 -> USB-OK[113] USB-OK[114] USB-OK[115] USB-OK[116] USB-OK[117] USB-OK[118] USB-OK[119] USB-OK[120] 11:11:53.264 -> USB-OK[121] USB-OK[122] USB-OK[123] USB-OK[124] USB-OK[125] USB-OK[126] USB-OK[127] USB-OK[128] 11:11:57.244 -> USB-OK[129] USB-OK[130] USB-OK[131] USB-OK[132] USB-OK[133] USB-OK[134] USB-OK[135] USB-OK[136] 11:12:01.231 -> USB-OK[137] USB-OK[138] USB-OK[139] USB-OK[140] USB-OK[141] USB-OK[142] USB-OK[143] USB-OK[144] 11:12:05.238 -> USB-OK[145] USB-OK[146] USB-OK[147] USB-OK[148] USB-OK[149] USB-OK[150] USB-OK[151] USB-OK[152] 11:12:09.226 -> USB-OK[153] USB-OK[154] USB-OK[155] USB-OK[156] USB-OK[157] USB-OK[158] USB-OK[159] USB-OK[160] 11:12:13.260 -> USB-OK[161] USB-OK[162] USB-OK[163] USB-OK[164] USB-OK[165] USB-OK[166] USB-OK[167] USB-OK[168] 11:12:17.236 -> USB-OK[169] USB-OK[170] USB-OK[171] USB-OK[172] USB-OK[173] USB-OK[174] USB-OK[175] USB-OK[176] 11:12:21.265 -> USB-OK[177] USB-OK[178] USB-OK[179] USB-OK[180] Not sure what I am supposed to see happen; I don't have another COM port listed on the Arduino IDE to look at. I added an led blink to the sketch and verified (somewhat to my surprise) that it continues to work when running off of just LiPo battery (so no USB connected). Then I removed the USB.h define from my usual blink sketch and it also works now without the USB connected (by battery). So this USB.h call might have been messing up the C3 behavior somehow. I will try my deep sleep sketch next to see if this runs as expected too. …

The issue that can be reproduced by the sketch is about ESP restarts when some Serial monitor connected to COM port of USB-CDC is closed. To see the result if the ESP restarts you need to connect USB cable to USB port on board (that will be UART - Serial) and 2nd cable to the USB-CDC pins (D- to GPIO18, D+ to GPIO19, 5V and GND) than you will see 2nd COM port for the USB-CDC. So open both ports (1st in Arduino IDE serial monitor and 2nd in some software like Putty). You should see in both "monitors" printed info USB-OK[] or UART-OK[]. Then if you close the USB-CDC monitor window the ESP will restart (or not - on macOS works fine) and if does you will see on UART monitor that the printing USB-OK[] starts again from 0.

Mar 28 '22 10:03 P-R-O-C-H-Y

@specternecter @kriswiner @P-R-O-C-H-Y

Let's keep it simple and address the initial issue. The original pain points are:

The first issue is that the USBSerial example for ESP32C3 in the Arduino IDE absolutely does not work for the C3.

Correct. All the examples of the same foder of USBSerial example will only work for the S2. They are all about TinyUSB and how to use it. None will work for the C3.

C3 has no full USB interface. It has just a JTAG/Serial that works as USB-CDC.

Because of it, it has a whole software layer just for the JTAG/Serial separated just for the C3. ESP32 C3 Arduino has its own events related to it. Therefore it's necessary to create a new example as already pointed out.

With the sketch I included, one of the issues is that after a reset, the USB doesn't work on the first opening of the port.

I guess this is about reseting the board right after uploading a new firmware/sketch using Arduino IDE and Win10. In that case, CDC works differently than UART. Serial Monitor Window is only valid while the USB CDC is working. If USB is unplugged, or the Board is turned off and on, or even reset, Windows must enumerate the USB CDC again and it causes the previous connexion to drop.

In the case of the IDE Serial Monitor window, when attached to a CDC port, it must be closed and a new window shall be open for the new USB enumeration.

If I use Putty for the serial monitor instead of the Arduino IDE Serial Monitor for the USB CDC Port, it will close the window right after a new sketch is uploaded and board is reset. To be more precise, it will close the Putty Serial Window right after the board enters in uploading mode, right before the upload starts.

This may be the reason for not being able to reproduce this specific issue with MacOS or Linux.

Thus, this is not an ESP32-C3 issue, but maybe an issue related to the way Arduino IDE windows version was built around an UART COM port Serial Monitor instead of a USB CDC COM port.

The major issue is that every time you first write to the USB port, it's somehow taking your written data and joining it after "ESP-ROM:esp32c3-api1-20210207\r\n", so you end up with "ESP-ROM:esp32c3-api1-20210207\r\n[YOUR DESIRED DATA]".

Correct. This will happen in the very first time the USB CDC port is written, as reported. I don't see any easy way to fix it at this time. Maybe the fuse suggestion from @igrr ?!

It may have to do with some sdkconfig setting for the JTAG... not sure.

It will require some investigation in order to fix it.

Please let keep it restricted to the original issue as above.

Any other issue shall have its own issue number (by opening a new issue). This way we will be able to better track it.

Mar 28 '22 11:03 SuGlider

I fixed many of the issues and identified what's needed to solve my original problem, as well as the last remaining problem I could identify. I created a feature request which includes a new USBSerial example for the ESP32C3.

https://github.com/espressif/arduino-esp32/issues/7779

Jan 31 '23 15:01 specternecter

I fixed many of the issues and identified what's needed to solve my original problem, as well as the last remaining problem I could identify. I created a feature request which includes a new USBSerial example for the ESP32C3.

#7779

If possible, please share your findings and solutions.

Feb 01 '23 19:02 SuGlider

ESP32-C3. USB to PC. custom board. no PSRAM. 4MB. i was working on my project that uses lot of serial output for the debugging purposes. it has been a long time for me to run it almost fully. imagine the .ino file is 1500 lines and i put around 300 serial print in special lines that shows me where the program is. it was working, i connected 2 devices to it and for more than 1 hour was watching the serial output. it also shows the used and free memory. after i was sure there is no leaking in memory, i decided to disconnect the USB cable (it runs from power supply) and watch it over the web what it does. as soon as i disconnect the USB cable, it freezed! i thought, oh, F! my program hanged. but then i tried it again and again and the same result. and few more test, then i found out when the USB is disconnected, it freeze . oh, and when i disconnect the USB while working, suddenly the memory gets full. 400 byte per second fast! why? i don't know. it is like USB serial buffer is getting full and hangs, but it doesn't reset. 10 sec later it starts working again. and no problem until i connect USB! then again freeze and the looping continuous. so much fun! what a great design. i thought this new chip was ok. but, nope! for real world work, the USB is useless, another great function from espressif. like the internal RTC. regards,

Mar 24 '23 10:03 josef2600

The problem isn't espressif. It's whoever is in charge of the CDC. Nobody seems to care about fixing the cdc. Instead of fixing, they suggest everybody a cheap work around to their problem and instead of looking at the changes I proposed, they complain about the way the formatting looks. Anyway, add these to your sketch folder and upload again. Bet your code works now. HWCDC.zip

If you've never done this before just open your sketch in Arduino, click the sketch menu, click add file and select the files here after unzipping. This will tell it to use these files instead of the native files when dealing with cdc. If it works (it should fix everything) then you can find the native files in the package and replace them with these. Just remember you had to do that because when you update the core, they'll be gone. They don't seem very interested in pushing the fix. Sort of a petty dispute between us about them not liking the format of the file rather than the fact these changes actually fix cdc. They don't seem to care about fixing it.

Mar 24 '23 11:03 specternecter

@specternecter thank you. but i would use the uart instead of usb. and it is in c++ that i don't like! but i am very grateful for your help. probably i will use it later. but the worth thing is the internal RTC. i cant figure out why are they doing that? how is that possible that they put a RTC with a special VDD for it, but nobody can use it like a human way! best regards, Josef.

Mar 24 '23 16:03 josef2600

@josef2600 In my experience, there's probably a good reason they're doing things that way. Core software development isn't always straightforward. It's likely that doing it in any different way causes an issue with some other function. With CDC, it just looks like they didn't spend enough time on it. With RTC there's probably a pretty good reason because something like that has a high potential to influence other things.

Mar 24 '23 17:03 specternecter

@kriswiner I'm not sure if this is linked to your issue but I was having trouble with my esp32-c3 freezing when no USB CDC serial connection was made when using the Serial.flush(); command on the USB CDC port. After I removed this call I could leave my Serial.print calls and the code continued to run as expected.

Aug 31 '23 01:08 beachmiles

my board is ESP32 C3 Supermini

After modifying Board.txt, the board reset disappeared when opening and closing the Arduino built-in serial monitor. However, a reset occurs when close the port in the serial port monitor program (Eltima). Both codes below appear to use HWCDC, but HWCDC does not have any code to disable DTR and RTS.

AppData\Local\Arduino15\packages\esp32\hardware......\board.txt

esp32c3.serial.disableDTR=true
esp32c3.serial.disableRTS=true

//USB-CDC on boot : DISABLED
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  USBSerial.begin();
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH); 
  USBSerial.println("USB");
  delay(1000);
}


//USB-CDC on boot : ENABLED
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin();
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH); 
  Serial.println("SERIAL");
  delay(1000);
}

My Windows programs cannot be modified. Is there a way to disable DTR and RTS in HWCDC?

Jan 28 '24 09:01 AtechLim

my board is ESP32 C3 Supermini

After modifying Board.txt, the board reset disappeared when opening and closing the Arduino built-in serial monitor. However, a reset occurs when close the port in the serial port monitor program (Eltima). Both codes below appear to use HWCDC, but HWCDC does not have any code to disable DTR and RTS.

AppData\Local\Arduino15\packages\esp32\hardware......\board.txt
esp32c3.serial.disableDTR=true
esp32c3.serial.disableRTS=true
//USB-CDC on boot : DISABLED
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  USBSerial.begin();
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH); 
  USBSerial.println("USB");
  delay(1000);
}


//USB-CDC on boot : ENABLED
void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin();
}

void loop() {
  digitalWrite(LED_BUILTIN, HIGH); 
  Serial.println("SERIAL");
  delay(1000);
}
My Windows programs cannot be modified. Is there a way to disable DTR and RTS in HWCDC?

And I read trm and studied about efuse. I tried DIS_USB_SERIAL_JTAG_DOWNLOAD_MODE, DIS_DOWNLOAD_MODE, and also disabled Joint Download Mode by connecting GPIO 8 to GND, but still my Esp32 c3 Supermini resets when I close the serial port. And I can't upload any more programs...

Jan 30 '24 09:01 AtechLim

arduino-esp32 arduino-esp32 copied to clipboard

Arduino IDE ESP32-C3 USB CDC problems

Board

Device Description

Hardware Configuration

Version

IDE Name

Operating System

Flash frequency

PSRAM enabled

Upload speed

Description

Sketch

Debug Message

Other Steps to Reproduce

I have checked existing issues, online documentation and the Troubleshooting Guide

Please let keep it restricted to the original issue as above.

arduino-esp32
arduino-esp32 copied to clipboard