Arduino IDE ESP32-C3 USB CDC problems

[specternecter]

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

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[igrr]

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!)

[kriswiner]

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?

[specternecter]

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 <#6089 (comment)>, 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: ***@***.***>

[kriswiner]

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 > < #6089 (comment) >, > 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 <#6089 (comment)>, 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: ***@***.***>

[specternecter]

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 > > < > #6089 (comment) > >, > > 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 > < #6089 (comment) >, > 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 <#6089 (comment)>, 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: ***@***.***>

[kriswiner]

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 > > > < > > > #6089 (comment) > > >, > > > 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 > > < > #6089 (comment) > >, > > 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 > < #6089 (comment) >, > 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 <#6089 (comment)>, 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: ***@***.***>

[specternecter]

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 > > > > < > > > > > > #6089 (comment) > > > >, > > > > 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 > > > < > > > #6089 (comment) > > >, > > > 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 > > < > #6089 (comment) > >, > > 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 > < #6089 (comment) >, > 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 <#6089 (comment)>, 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: ***@***.***>

[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 > > > > > < > > > > > > > > > > #6089 (comment) > > > > >, > > > > > 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 > > > > < > > > > > > #6089 (comment) > > > >, > > > > 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 > > > < > > > #6089 (comment) > > >, > > > 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 > > < > #6089 (comment) > >, > > 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 > <#6089 (comment)>, > 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: > ***@***.***> >

[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.

[P-R-O-C-H-Y]

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.