Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Arduino IDE ESP32-C3 USB CDC problems #6089

Closed
1 task done
specternecter opened this issue Jan 1, 2022 · 35 comments · Fixed by #9275
Closed
1 task done

Arduino IDE ESP32-C3 USB CDC problems #6089

specternecter opened this issue Jan 1, 2022 · 35 comments · Fixed by #9275
Assignees
@SuGlider
Labels
Chip: ESP32-C3 Issue is related to support of ESP32-C3 Chip Status: Awaiting triage Issue is waiting for triage

Comments

@specternecter
Copy link

specternecter commented Jan 1, 2022 •
edited
Loading

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.
@specternecter specternecter added the Status: Awaiting triage Issue is waiting for triage label Jan 1, 2022
@igrr
Copy link
Member

igrr commented Jan 1, 2022

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

@VojtechBartoska VojtechBartoska added the Chip: ESP32-C3 Issue is related to support of ESP32-C3 Chip label Jan 4, 2022
@kriswiner
Copy link

kriswiner commented Feb 27, 2022 •
edited
Loading

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
Copy link
Author

specternecter commented Feb 27, 2022 via email

@kriswiner
Copy link

kriswiner commented Feb 27, 2022 via email

@specternecter
Copy link
Author

specternecter commented Feb 27, 2022 via email

@kriswiner
Copy link

kriswiner commented Feb 27, 2022 via email

@specternecter
Copy link
Author

specternecter commented Feb 27, 2022 via email

@specternecter
Copy link
Author

specternecter commented Feb 27, 2022 via email

@specternecter
Copy link
Author

specternecter commented Mar 20, 2022 •
edited
Loading

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
Copy link
Member

P-R-O-C-H-Y commented Mar 22, 2022 •
edited
Loading

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.

@specternecter
Copy link
Author

specternecter commented Mar 22, 2022 via email

@kriswiner
Copy link

kriswiner commented Mar 22, 2022 via email

@VojtechBartoska VojtechBartoska moved this from Todo to Under investigation in Arduino ESP32 Core Project Roadmap Mar 23, 2022
@VojtechBartoska VojtechBartoska added this to the 2.0.3 milestone Mar 23, 2022
@VojtechBartoska VojtechBartoska moved this from Under investigation to In Progress in Arduino ESP32 Core Project Roadmap Mar 23, 2022
@VojtechBartoska VojtechBartoska moved this from In Progress to Under investigation in Arduino ESP32 Core Project Roadmap Mar 23, 2022
@P-R-O-C-H-Y
Copy link
Member

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.

@kriswiner
Copy link

kriswiner commented Mar 24, 2022 via email

@specternecter
Copy link
Author

specternecter commented Mar 24, 2022 via email

@P-R-O-C-H-Y
Copy link
Member

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.

@kriswiner
Copy link

kriswiner commented Mar 25, 2022 via email

@kriswiner
Copy link

kriswiner commented Mar 25, 2022 via email

@kriswiner
Copy link

kriswiner commented Mar 25, 2022 via email

@P-R-O-C-H-Y
Copy link
Member

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.

@SuGlider SuGlider self-assigned this Mar 28, 2022
@SuGlider
Copy link
Collaborator

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

@Jason2866 Jason2866 mentioned this issue Apr 3, 2022
Closed
1 task
@VojtechBartoska VojtechBartoska modified the milestones: 2.0.3, 2.1.0 Apr 28, 2022
@Jason2866 Jason2866 mentioned this issue May 17, 2022
Merged
6 tasks
@VojtechBartoska VojtechBartoska removed this from the 2.0.6 milestone Nov 30, 2022
@specternecter
Copy link
Author

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

@SuGlider
Copy link
Collaborator

SuGlider commented Feb 1, 2023

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.

@SuGlider SuGlider mentioned this issue Feb 1, 2023
Closed
@josef2600
Copy link

josef2600 commented Mar 24, 2023 •
edited
Loading

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,

@specternecter
Copy link
Author

specternecter commented Mar 24, 2023 •
edited
Loading

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.

@josef2600
Copy link

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

@josef2600 josef2600 mentioned this issue Mar 24, 2023
Closed
@specternecter
Copy link
Author

specternecter commented Mar 24, 2023 •
edited
Loading

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

@beachmiles
Copy link

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

@AtechLim
Copy link

AtechLim commented Jan 28, 2024 •
edited
Loading

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?

@AtechLim
Copy link

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

@AtechLim
Copy link

And everything works perfectly in esp32 s3 devkit. I ordered ESP32 S3 ZERO board.

@SuGlider SuGlider mentioned this issue Feb 28, 2024
Merged
@github-project-automation github-project-automation bot moved this from Under investigation to Done in Arduino ESP32 Core Project Roadmap Feb 28, 2024
@SuGlider
Copy link
Collaborator

@specternecter @kriswiner @josef2600 @AtechLim @igrr

The original issue is related to the JTAG/HW CDC Serial peripheral from ESP32-S3, ESP32-C3, ESP32-C6 and ESP32-H2.

One issue is that when USB cable is unplugged, flush() will block and write() will also block as soon as the HWCDC Ringbuffer gets full.

The second issue is that It won't work properly when the sketch waits for the CDC to be connected using a Serial Monitor, using a code like while(!Serial) delay(100);

These and some other issues were fixed by the PR #9275

When USB is unplugged, nothing will block any HW CDC writing or flushing.
When the buffer gets full, its content will be discarted and it will show the latest written data.
By this way, when the sketch connects to a serial monitor, it will display the latest data flow.

bool HWCDC will return true only when CDC is connected using some Serial Monitor Application.
It is possible plug, unplug, open and close the terminal that it will work correctly.
Closing the terminal while using Windows 10/11 will reset the board because for some reason Windows raises USB ACM RTS that makes the board consider that it shall reset. But it is possible to unplug the cable and the software will detect it and adjust its status to indicate that the CDC connection has been terminated. It is possbile to plug back the USB cable and reconnect automatically by opening the serial monitor again.

It has been fixed for arduino core 3.0.0-RC1 and it is available in the master branch.

Check the PR examples.

@josef2600
Copy link

@specternecter @kriswiner @josef2600 @AtechLim @igrr

The original issue is related to the JTAG/HW CDC Serial peripheral from ESP32-S3, ESP32-C3, ESP32-C6 and ESP32-H2.

One issue is that when USB cable is unplugged, flush() will block and write() will also block as soon as the HWCDC Ringbuffer gets full.

The second issue is that It won't work properly when the sketch waits for the CDC to be connected using a Serial Monitor, using a code like while(!Serial) delay(100);

These and some other issues were fixed by the PR #9275

When USB is unplugged, nothing will block any HW CDC writing or flushing. When the buffer gets full, its content will be discarted and it will show the latest written data. By this way, when the sketch connects to a serial monitor, it will display the latest data flow.

bool HWCDC will return true only when CDC is connected using some Serial Monitor Application. It is possible plug, unplug, open and close the terminal that it will work correctly. Closing the terminal while using Windows 10/11 will reset the board because for some reason Windows raises USB ACM RTS that makes the board consider that it shall reset. But it is possible to unplug the cable and the software will detect it and adjust its status to indicate that the CDC connection has been terminated. It is possbile to plug back the USB cable and reconnect automatically by opening the serial monitor again.

It has been fixed for arduino core 3.0.0-RC1 and it is available in the master branch.

Check the PR examples.

thank you. it is great! except i cant use Arduino core 3.0.0 !! it is so bad and unstable that no code of min can work with it. they have changed all the networking and removed a ton of libraries and made stupid changes to hardware libraries that causes so many errors in my codes. so, my only solution was to say shit with it and back to core 2 and stop using it! in general, i am working with a lot of anger!

@SuGlider
Copy link
Collaborator

SuGlider commented Mar 1, 2024

@josef2600 - I understand your point of view.
We are working to release a stable version.
3.0.0 is currently under development.

In the meantime, please feel free to post new questions or issue for the community.

@Rob58329
Copy link
Contributor

Arduino IDE ESP32-C3 USB CDC problems

Just in case it’s useful for anybody, I experienced an unusual issue when trying to upload a sketch from the Arduino IDE via the USB-CDC. After working fine for some days the upload just stopped working, hanging at the “Running stub...” point.

Interestingly, the “USB CDC on Boot: ENABLED” still worked fine, and I could see data (Serial.print statements) coming from the ESP32-C3 fine, I just could not upload anything new.

Also interestingly I could still upload new sketches using a separate USB-to-Serial adapter and the ESP32-C3 pins 20 (UART0 Rx) and 21 (UART0 Tx).

The issue actually turned out to be the Windows-PC’s USB adapter which had partially stopped working in some way, and a simple PC-reboot fixed it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@SuGlider SuGlider

Labels
Chip: ESP32-C3 Issue is related to support of ESP32-C3 Chip Status: Awaiting triage Issue is waiting for triage
Projects
Arduino ESP32 Core Project Roadmap
Archived in project
Milestone
No milestone
10 participants
@beachmiles @igrr @kriswiner @josef2600 @Rob58329 @SuGlider @VojtechBartoska @P-R-O-C-H-Y @AtechLim @specternecter