v3.0 couldn't keep the correct serial port with Arduino Nano ESP32 once RST button is pressed

[riywo]

Board

Arduino Nano ESP32

Device Description

Vanilla Arduino Nano ESP32

Hardware Configuration

No GPIO

Version

v3.0.2

IDE Name

Arduino IDE

Operating System

Windows 11

Flash frequency

?

PSRAM enabled

no

Upload speed

115200

Description

I tried to use v3.0.2 of esp32 board manager with Arduino Nano ESP32 but it couldn't keep the correct serial port. Let me describe the repro steps (I'm using Arduino IDE):

1. Enter the ROM Boot Mode (i.e. firmware download mode, see also this doc)
2. Select COM11 (ESP32 Family Device)
3. Upload Using Programmer (Esptool) with AnalogReadSerial example sketch
4. Press RST button
5. However, the serial port is still COM11 (ESP32 Family Device) and no output is coming

The only way to work with v3.0.2 is entering Bootloader-mode, then COM12 (Arduino Nano ESP32, Arduino Nano ESP32) is showed up. Once I upload the same sketch without Programmer, serial output works. However, when I press RST button, COM12 is gone and COM11 is back. In other words, the workaround is that using Bootloader-mode whenever I reset the board, that is insane.

This behavior only happens with v3.0 of esp32, though. I checked v2.0.17 of esp32, then RST button correctly keeps COM12 and the serial port is working. Same as the Arduino's Arduino ESP32 Boards, RST keeps COM12.

Sketch

// the setup routine runs once when you press reset:
void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(9600);
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input on analog pin 0:
  int sensorValue = analogRead(A0);
  // print out the value you read:
  Serial.println(sensorValue);
  delay(1);  // delay in between reads for stability
}

Debug Message

N/A

Other Steps to Reproduce

Note: When I use Blink sketch, LED properly blinks after RST even though the serial port is wrong (COM11).

Note: When the correct port is showed up (i.e. after uploading with Bootloader-mode), physically reconnecting USB cable still remains the correct port (COM12). However, once I press RST button, it never goes back to COM12 even after reconnecting USB cable again. Bootloader-mode is the only way to recover. => Update: The first half isn't true. It sometimes changes to the wrong port by just reconnecting USB cable.

Note: Also, re-uploading a new sketch when the correct port is showed up doesn't change the serial port. Only pressing RST button triggers this problematic behavior.

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

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

[me-no-dev]

cc @pillo79

[pillo79]

@riywo thanks for the detailed report! We will try to investigate and let you know.

[riywo]

@pillo79 Please let me know if any more data you need from my board for your further investigation. This issue is pretty annoying to me as I can't run my sketch on Arduino Nano ESP32 without USB serial connection (USB battery won't work). I really want to workaround this issue.

BTW, the reason why I want to use v3.0 is the new I2S library. It's cool!

[riywo]

Another finding if it helps: I tried to use 5V VIN today.

• When I powered on the 5V battery, my sketch didn't start
• Then, when I plugged USB cable with Arduino IDE, my sketch did start automatically
• Then, once I pressed RST, the port was gone like above (COM11) and my sketch never started
• Then, I reconnected USB cable and my sketch restarted as well as the port was back normal (COM12)!
• Then, I unplugged USB cable and my sketch kept running!!

So, by this way, I could use this board without USB serial somehow (Power on 5V VIN, plug USB serial then unplug). Hope this helps the investigation...

[pillo79]

Thanks for these updates! I see you are referring to multiple ways of powering the board - does this issue happen also in the simplest case, with a Blink sketch and no electronics attached except for the USB-C cable powering the board?
If this is true I would concentrate on this situation since it is much easier to replicate.

I tried to do so in Linux using IDE 2.3.2, ESP32 core rev 3.0.2 and FQBN esp32:esp32:nano_nora, but I could not: a single "Upload with programmer" here does result in a correct flash and the DFU works just after the first reset (so it would have been detected as your COM12, if I understand correctly).

I am not very skilled in Windows issues. I have escalated this internally so someone can try and replicate on a Windows machine. We haven't yet completed these tests for 3.0, so for the time being we still advise Nano ESP32 users to hold on 2.0.x (2.0.17 will soon be released!) for stability. But thanks for being on the bleeding edge and providing feedback!

[riywo]

@pillo79 Thank you for your investigation! Yes, it happens with the simplest case:

• Environment
  • Windows 11
  • Arduino IDE 2.3.2
  • esp32 board manager 3.0.2 (I guess FQBN is esp32:esp32:nano_nora, too)
  • Only USB-C cable is connected (no VIN)

esptool.py v4.6
Serial port COM11
Chip is ESP32-S3 (revision v0.2)
Features: WiFi, BLE
Crystal is 40MHz

• Symptom
  1. Enter the ROM Boot Mode (i.e. firmware download mode, see also this doc)
  2. Select COM11 (ESP32 Family Device)
  3. Upload Using Programmer (Esptool) with the Blink.ino example sketch
  4. Press RST button
  5. However, the serial port is still COM11 (ESP32 Family Device)
     • Note: Built-in LED is blinking, though

I have Raspberry Pi 5, so let me try Linux later!

[JAndrassy]

and if you then do a normal upload from IDE?

[riywo]

@JAndrassy Thank you for the suggestion. It can't upload through COM11 because "USB DFU" isn't working properly? (I can't see something like "2-5 USB DFU" with COM11 while there is with COM12):

Sketch uses 325557 bytes (10%) of program storage space. Maximum is 3145728 bytes.
Global variables use 30696 bytes (9%) of dynamic memory, leaving 296984 bytes for local variables. Maximum is 327680 bytes.
dfu-util 0.11-arduino4

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

No DFU capable USB device available
Failed uploading: uploading error: exit status 74

[riywo]

Arduino IDE 2 doesn't support ARM, so I couldn't try Linux on Raspberry Pi. Thus, I tried macOS Apple Silicon instead. In summary, it worked well, so the problem looks like happening only on (my) Windows.

• Environment
  • macOS 14.5
  • Apple Silicon M1 Pro
  • Arduino IDE 2.3.2
  • esp32 v3.0.2
  • USB-C cable only
• Symptom
  • Enter the ROM Boot Mode (i.e. firmware download mode, see also this doc)
  • Select /dev/cu.usbmodem112101 (ESP32 Family Device)
  • Upload Using Programmer (Esptool) with the Blink.ino example sketch
  • Press RST button
  • Now, the previous port disappeared and a new one /dev/cu.usbmodem744DBDA24DA42 (Arduino Nano ESP32) showed up
  • Once I switched Arduino IDE to the new port, of course I can normally upload the sketch as well as RST button properly resets and the same serial port remains working well

[JAndrassy]

and on Windows you can do a normal upload to COM12 after you uploaded Blink with esptool?

[riywo]

Sure as long as COM12 is active. The problem is that whenever I press RST or reconnect USB-C cable, it goes back to COM11 and I need to enable Bootloader-mode (press RST twice) that activates COM12 then I need to re-upload the same sketch again.

[JAndrassy]

after the reset/reconnect normal upload to COM11 doesn't work?

[riywo]

No, never. COM11 can only work with ROM Boot Mode but normal upload won't work.

[DonWT]

I see the same problem on my Win11 computer using the Arduino IDE 2.3.2 and both a Nano ESP32 and a Waveshare clone of the Nano ESP32 (a Waveshare ESP32-S3-Nano) and version 3.0.3 of the Espressif esp32 board manager.

If I configure the board to use the Arduino ESP32 Boards version 2.0.13 board manager then I do not see this problem.

I used the standard 'Blink' sketch with an added Serial.println statement:

// the setup function runs once when you press reset or power the board
void setup() {
  // initialize digital pin LED_BUILTIN as an output.
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
  delay(2000);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(LED_BUILTIN, HIGH);  // turn the LED on (HIGH is the voltage level)
  delay(1000);                      // wait for a second
  digitalWrite(LED_BUILTIN, LOW);   // turn the LED off by making the voltage LOW
  delay(1000);                      // wait for a second
  Serial.println("Here");
}

I am using a 'bare' Arduino Nano ESP32 with no additional circuitry. I am using the Arduino IDE 2.3.2 on a Windows 11 computer.

Arduino ESP32 Boards by Arduino:

Compile and (normal) upload with the board set to 'Arduino Nano ESP32' using the 'Arduino ESP32 Boards' version 2.0.13

1. Compiles and uploads OK, flashes LED and prints 'Here' every two seconds.

2. Press reset and the board disconnects briefly then reconnects and works the same as in 1.

3. Disconnect and reconnect the USB cable and the board restarts and works the same as in 1.

4. Redo the compile and upload without going into boot mode and, again, it works the same as in 1.

All as expected.

esp32 boards by Espressif:

Compile and upload with the board set to 'Arduino Nano ESP32' using the 'esp 32 boards' version 3.0.3

1. Compiles and (normal) uploads OK, flashes LED and prints 'Here' every two seconds.

2. Press reset and the board disconnects and stays disconnected, LED flashes but no serial prints. Notifications say:
   Port monitor error: command 'open' failed: Serial port not found. Could not connect to COM4 serial port.
   Compile and upload now fails with:
   No DFU capable USB device available
   Failed uploading: uploading error: exit status 74

3. (I needed to double press the reset button to get it to compile and upload.)
   Disconnect and reconnect the USB cable and the board restarts, the LED flashes but, again, it fails to connect so there are no serial prints. Same notifications as in 2. Again, I need to double press the reset button to go into boot mode before I can compile and upload again.

[dquadros]

Just saying that I got the same problem.

Arduino uses the DFU mode for upload, if you download to the Nano ESP32 a program compiled with the Espresif package, after you unplug and replug the board, there is a "USB JTAG debug unit" instead of the DFU device and the COM port does not work. If you change the USB Mode to Debug Mode (Hardware CDC) the COM port works (but you do not have the DFU device, so normal download cannot be used).

[dquadros]

I tried to do so in Linux using IDE 2.3.2, ESP32 core rev 3.0.2 and FQBN esp32:esp32:nano_nora, but I could not: a single "Upload with programmer" here does result in a correct flash and the DFU works just after the first reset (so it would have been detected as your COM12, if I understand correctly).

Just tried under Linux Mint 22, IDE 2.3.3. ESP32 core 3.0.5. board "Arduino Nano ESP32" and reproduced the problem: "No DFU" when trying to upload the Blink sketch (after successfully uploading using the "upload with programmer"). Using the "Arduino ESP32 boards" package it worked fine (but I had to set up a udev rule, as stated on https://forum.arduino.cc/t/upload-on-linux-fails-no-dfu-capable-usb-device-available/1252666/3).

I noticed that the VID/PID is different (2341/0070 for Aduino, 303a/1001 for Espressif) and tried a udev rule using the Espressif vid/pid but it made no difference.

[pillo79]

Just tried under Linux Mint 22, IDE 2.3.3. ESP32 core 3.0.5. board "Arduino Nano ESP32" and reproduced the problem: "No DFU" when trying to upload the Blink sketch (after successfully uploading using the "upload with programmer").
[...]
I noticed that the VID/PID is different (2341/0070 for Aduino, 303a/1001 for Espressif) and tried a udev rule using the Espressif vid/pid but it made no difference.

@dquadros thanks for the feedback. Did the "Upload using programmer" use esptool or DFU? Also, just to confirm, exactly when is the VID/PID different in your case?

[dquadros]

@dquadros thanks for the feedback. Did the "Upload using programmer" use esptool or DFU? Also, just to confirm, exactly when is the VID/PID different in your case?

The "Upload using programmer" uses esptool.

There are two packages that support the Arduino Nano ESP32 board:

• "Arduino ESP32 boards" by Arduino: this is based on a old version of arduino-esp. DFU works when this is used and the board shows up with VID=2341 and PID=0070
• "esp32" by Espressif: DFU is not available when this is used and the board shows up with VID=303a and PID=1001

Hope this helps to identify the issue!

[ednieuw]

With 3.0.5 I had this issue so now and then but now with core 3.0.7 I can upload, see COM13 in my case and see serial communication but the RGB LED on the Nano ESP32 board does not blink as it should in my sketch every second.
It stays on and commands (via UART Bluetooth connection) to turn it off does not work.
Two other one color LEDs connected to D9 and D10 blink as expected every second and the program runs with WIFI/NTP connection, WS2812 LED-strip and more works fine.
After pressing the reset button the COM13 port disappears and becomes COM12 (ESP32 Family Device).
So two problems: RGB LED on Nano ESP32 board does not work and serial connection disappears after a reset

[boerge1]

Same problem here:

Arch Linux
Arduino ESP32 Nano

With arduino-esp32 V2.0.17 all works fine.
With arduino-esp32 V3.1.3 the USB connection is broken after reset or power down/up
I could live with it using the double reset before uploading, but also the serial monitor does not work when the USB port is broken.

[Jason2866]

Closing since a 3rd party hardware board. Please open an issue at the manufacturer repo.

[DonWT]

How can you simply close this issue when it has been reported against several boards and used to work in earlier versions of Espressif's board manager?

[Jason2866]

@DonWT The board is not manufactured from espressif. 3rd party boards issues needs to be fixed from the manufacturer of the board.

[Jason2866]

@pillo79 Are you going to fix the issue with your board?

[pillo79]

@Jason2866 Closing an issue as "completed" looks weird to me as well honestly, this is clearly not solved for the affected users, and GH issues are a super helpful way to get user feedback.

On topic, I am sorry but... still not able to reproduce this.
@DonWT @ednieuw @boerge1 @dquadros, if anyone of you with this issue can do an additional test, I have another idea.
After putting the board in "bootloader mode" (B1+GND shorted, press and release RESET), can you try the real "Burn Bootloader" command in the IDE Tools menu, and then "Upload using Programmer" a blink sketch?
This will have the effect of fully erasing the board Flash memory before restoring a blink, and might change the situation.

[Jason2866]

@pillo79 Imho This issue should have been not accepted here in general. Arduino code developers don't know this board (and are not responsible for).
At least closing this started some action ;-)

[DonWT]

@pillo79

On topic, I am sorry but... still not able to reproduce this. @DonWT @ednieuw @boerge1 @dquadros, if anyone of you with this issue can do an additional test, I have another idea. After putting the board in "bootloader mode" (B1+GND shorted, press and release RESET), can you try the real "Burn Bootloader" command in the IDE Tools menu, and then "Upload using Programmer" a blink sketch? This will have the effect of fully erasing the board Flash memory before restoring a blink, and might change the situation.

Luca: Sorry for the delay in responding.

I am testing using my lightly modified Blink sketch that I posted earlier: #10025 (comment)

Test 1 The same code using the Arduino ESP32 Boards version 2.0.18-arduino.5

Using this version of the Arduino version of the ESP32 board I get the problem of the serial port being changed after pressing reset or unplugging and re-plugging the USB port.

Test 2 The same code using an old version of the Arduino ESP32 board, this time version 2.0.13

Now everything works as expected, pressing reset or disconnecting the USB port does not change the serial port.

Test 3 The same code using the Espressif board manager version 3.1.1

This fails in the same way as Test 1.

After a couple of tries I managed to burn a new boot loader and upload the blink sketch using the Programmer.

I seem to have everything working now once I did the following:

1. Set the board to be Arduino Nano ESP32 - it does not matter if you use the Arduino ESP32 Boards or the Espressif esp32.
2. Jumper B1 to ground, press reset and the remove the jumper.
3. Tools-> Burn Bootloader
4. Compile the modified Blink sketch then Upload Using Programmer
5. Press reset and change the COM port to the one in use now.
6. The sketch runs and does not lose the COM port after a reset or power down/up

I can now recompile and normal upload and that now works OK.

[ednieuw]

That was a good thought; using 2.0.13
I am not at home for two weeks but my solution when trying out esp32 core 3 and loosing the com port was revert back to the Arduino esp32 nano core 2.0.17. Upload Blink and unplug the usb cable. The sketch I work on is rather big and uses many libraries. Some are not compatible with core 3.0 but 3.0 has a lot of functionality and some of the libraries can be replaced.
For me it is not clear what causes loosing the COM-port. It seems occurring random but can also be caused by an out of memory program error. (My guess) Maybe in Wire or another basic library
I am always happy when the ESP32 Nano works after some fiddling works again.
I once replaced the bootloader with core 3.0 installed. Replacing was possible but I did not notice a difference at that moment.
It is probably wise to use the bootloader from the core version working with.

[pillo79]

@DonWT thanks for this news, that appears to be a fantastic result! 😁
I do not know the specifics, but if "Burn bootloader" solved the issue, then something that was written in the Flash was confusing the Arduino boot stage, and manually erasing the Flash restored the correct behavior. 🥳
Will make sure to add a mention to this in the Nano ESP32 Cheat sheet and/or Bootloader update pages on the web site!

[DonWT]

Luca BTW. The bootloader update page is missing the step about using Tools->Burn Bootloader. I also raised this issue on the Arduino forum: https://forum.arduino.cc/t/midi-usb-on-the-nano-esp32/1162846/33?u=dtone1 After I have done a bit more experimenting then I will post the solution there. (Are you ptillisch <https://forum.arduino.cc/u/ptillisch>?) A question: Do you know if there was an update to the bootloader firmware at any time? I bought my Nano ESP32 fairly soon after they first came out. Or is there some way that the bootloader firmware could have been changed? Don.

…

On Fri, 14 Mar 2025 at 04:25, Luca Burelli ***@***.***> wrote: @DonWT <https://github.com/DonWT> thanks for this news, that appears to be a fantastic result! 😁 I do not know the specifics, but if *"Burn bootloader"* solved the issue, then something that was written in the Flash was confusing the Arduino boot stage, and manually erasing the Flash restored the correct behavior. 🥳 Will make sure to add a mention to this in the Nano ESP32 Cheat sheet <https://docs.arduino.cc/tutorials/nano-esp32/cheat-sheet/> and/or Bootloader update <https://support.arduino.cc/hc/en-us/articles/9810414060188-Reset-the-Arduino-bootloader-on-the-Nano-ESP32> pages on the web site! — Reply to this email directly, view it on GitHub <#10025 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAIB5KSVBCGM4AVXJDUBUUL2UKG7TAVCNFSM6AAAAABK27ZNPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRTHE3TINBRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: pillo79]*pillo79* left a comment (espressif/arduino-esp32#10025) <#10025 (comment)> @DonWT <https://github.com/DonWT> thanks for this news, that appears to be a fantastic result! 😁 I do not know the specifics, but if *"Burn bootloader"* solved the issue, then something that was written in the Flash was confusing the Arduino boot stage, and manually erasing the Flash restored the correct behavior. 🥳 Will make sure to add a mention to this in the Nano ESP32 Cheat sheet <https://docs.arduino.cc/tutorials/nano-esp32/cheat-sheet/> and/or Bootloader update <https://support.arduino.cc/hc/en-us/articles/9810414060188-Reset-the-Arduino-bootloader-on-the-Nano-ESP32> pages on the web site! — Reply to this email directly, view it on GitHub <#10025 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAIB5KSVBCGM4AVXJDUBUUL2UKG7TAVCNFSM6AAAAABK27ZNPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMRTHE3TINBRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[dquadros]

Let me start by explaining that I want to use the Espressif ESP32 package with the Arduino Nano ESP 32 board because it is based on a more recent IDF version and it is updated more frequently. The Arduino Nano ESP32 (and many other third-party boards) is explicitly supported by the Espressif package.

I made some new tests with version 3.1.1, starting with using the Burn Bootloader. Long story short, it works as long as Programmer is esptopl (it is the only option but sometimes it is not selected), I short B1 to ground and use Upload Using Programmer. Normal upload will not work (also upload using programmer if the board is not placed in boot mode by B1). I may be wrong (this happens a lot), but I believe using this procedure will bypass the normal Arduino Bootloader.

Things got worse when I updated to version 3.1.3, I got compiler errors in the standard Blink example. The same thing happened with other examples. Changing to another board (XIAO ESP32-S3), compilation was ok, so it look likes something specific to the Nano ESP32.