I seem to be running into the same issues as some previous users. I've looked through the forums for a solution but came up emtpy.
My steps were as follows:
- Turn on PC (Windows 10 Enterprise 22H2)
- Start up Arduino IDE 2.2.1
- Connect my Arduino Nano ESP32
- From the drop-down in IDE, select Arduino Nano ESP32, selcct COM3 Serial Port (USB)
- From the tools menu, verify COM3 (UM Tiny S3) is selected for Port.
- Verify pin numbering is 'By Arduino Pin'
- Verify USB Mode: Normal Mode (TinyUSB)
- Verify Programmer is esptool.
My first attempt was from the drop-down 'Sketch' and select 'Upload using Programmer' and this failed. See picture for COM3. The second attempt was to put the board into Bootloader Mode and same steps as above except its COM4 (ESP32C3 Dev Module) with no success. See picture for COM4 attempt.
My only installed packages are:
Arduino AVR Boards 1.8.6
Arduino ESP32 Boards 2.0.13
I installed esp32 by Espressif Systems 2.0.11, then uninstalled it.
Any help is greatly appreciated. This is the third computer I've tried it on, and used the original apple USB-C to connect to this third PC and a USB3.0 to USB-C cable that i had, both with no success.
Welcome to the forum
Why select this option when you have a USB connection ?
Hello @mr_ngineer, I think you are missing one step in your bullet list - before "Upload using programmer", you should enter ROM bootloader mode by shorting pin B1 with GND and shortly pressing RESET. See this article for more info and let me know your results!
Edit: Re-read your post, I see that you already did that. More questions for you then 
- When in ROM bootloader mode, do you have a steady, dim light on the RGB LED?
- In the Windows Device Manager, is the Nano ESP32 recognized like the following picture?
- Does the board briefly disappear from the Windows Device Manager when you click on "Upload using programmer"?
Hey Iburelli,
When it's in ROM bootloader mode, I have a steady dim light that appears purple.
Here is the Windows Device Manager picture, both items appear that you ask about.
The board does not briefly disappear from the Windows Device Manager before, during, or after "Upload using programmer' is selected. However, I can see Windows refreshing Device Manager but I don't notice anything briefly appearing or disappearing.
And can you confirm the status of the LED that is displaying the purple color whenever the reset button is at that point pressed twice?
I haven't had much success in doing the reset push button twice method. I seem to miss the window of when to push it again. I've always resorted to this method. It maintains the purple color though.
That's interesting. After following the procedure at that link, you should be able to time it so the second press happens while the colors are changing on the LED.
You see the colors fade briefly after each RESET, right?
So when I plug in my board, it immediately is running the preloaded software from factory. It is blinking the red, green, and blue LED in a sequence. This at least confirms it's running something. If I press the reset button, the LED sequence does stop, and the colors fade away. If I let go of the reset button, the LED sequence begins again....red, green, and blue in a sequence.
I've always just jumpered B1 to ground in order to get it into bootloader mode to attempt to upload my own software because its easier.
Does the double reset put the board into another mode other than bootloader?
Is this board a dud and should I start thinking of replacing it?
Your previous replies suggest that the board and cables are doing perfectly fine AFAICS. What you just described is the sketch we preload at the factory.
This also means that none of your tests ever changed its programming, however! 
By the way, yes, double tap is different from ROM bootloader - you can find more info in the Cheat Sheet. The short answer is, usually you should use the "Upload" button, unless you are updating the bootloader by entering the ROM via the B1+GND trick - only then you should use "Upload using programmer".
Do you have the same error messages on all the PCs you have tried?
The first laptop was a MB air 2017 and that one didn't identify the board correctly. I would look at the system report and it was showing a different manufacturer for the board plugged in to the USB. My 27" iMac was doing the same thing. Due to the fact I couldn't figure out if the JTAG was showing up, I resorted to the current windows PC where I felt more comfortable troubleshooting. This windows PC is also a much newer PC, which I thought would have the correct drivers installed to start with.
Is there an opportunity that I messed up sectors within the bootloader? Could that 'brick' the arduino in some way that I cannot upload any sketches?
I'll have to see if i can do the double reset method so I can use the "upload" button and see what the results are.
PS. One thing to note is that one time on the MB laptop I got a error trying to upload sketches and it was something along the lines of the baud rate.
No way. If you enter the ROM bootloader properly (dim light + board reports as a "JTAG serial debug unit"), the contents of the Flash are irrelevant - everything was done by unchangeable ROM in the CPU itself. That's why it's the preferred way to recover from flashing issues or load non-Arduino firmwares.
I would say there's something strange in your Windows PC that makes the upload fail, but it's unclear to me what it is...
That's quite OK in fact: you can't reliably identify the board when in ROM bootloader mode, essentially any board with the same CPU appears the same, and there are tons!
Can you try the full restore bootloader sequence from this computer again?
I will try that tonight when I get home using my MB laptop to see what the restore bootloader does.
I wanted to add using my Windows PC
attempting to enter boatloader mode using the reset button, I don't see what the Cheat Sheet suggests. After pressing it once, I do not see the RGB flashing. It just seems to restart the factory blinking program.
I'll look more closely tonight as well to see if it indeed does 'flash' when I press it once.
1 Like
Here is a snippet of restoring the boot loader using my MB laptop. This appears to have been successful.
However, when I switch back to my Windows PC. Plugging the Arduino Nano in, I notice that something is recognized by the PC, like a device was plugged in, and then a second later, like the device has been disconnected. It repeats this pattern forever every second. So connect, then disconnect. The IDE status bar at the bottom is showing the same behavior. Shows connected, then disconnected. If I place the Nano in DFU mode and try to restore the boatloader, this is the error I get. I realize I already accomplished this with the MB in my previous step, but I wanted to see if the IDE was capable of restoring the boot loader and it has issues.
Is this a driver issue if Windows is recognizing a device being connected and disconnected?
Wanted to provide an update tonight about the success I had.
I went back to my MB and restored the bootloader. Yet again after post #36. I then attempted to burn an example 'blink' program and saw that I had success only after placing the board in DFU mode. The double reset method is still foreign to me and I can't seem to get the right sequence to do it. Regardless, I realized this worked on my old laptop. I then did another bootloader restore to prepare the nano for my Windows pc.
I then proceeded to restore the bootloader on my Windows PC (redundant) but wanted to see if the pc could do this procedure. And success! I then attempted to upload the 'blink' example and had to do the DFU mode as I did with my MB and success!
In summary, I want to say resorting back to the MB and restoring the bootloader did the magic. As a matter of fact, I want to say that after post #35 it was probably already working for my Windows PC but did not do the right procedure to upload an example at the time.
Thank you for you help.
1 Like
Thank you for your detailed updates. Yes, I believe post #35 shows a "Burn bootloader" execution instead of "Upload using programmer" as mentioned in the guide. No biggie, just some more experiments
Glad you made it work though! Happy hacking 
Hello,
I have same problem as mr_ngineer, I have tried the Bootloader method by shorting GND and B1 pin. However when I exit the mode, now my IDE does not recognises the arduino. Earlier before I attempted it could recognise it but I was getting other errors, NO DFU Device available.
Could you please help me, as I am new to Arduino world?
Hello @utahir201, it's possible that something went wrong on the board recovery procedure.
Please follow all the steps in the guide carefully, and let us know about anything you have to do differently compared to what's written there.
@lburelli reflecting back on my initial steps and what I may have done wrong, I am able to put my arduino nano into this mode successfully 100% of the time now.
If you recall from the posts above, I was having no luck in getting my nano into this mode at all. So, here’s my question that could help identify the issue @utahir201 may be having.
Is there a way of accidentally loading the wrong boot loader if you leave the generic board selection by the IDE? For example, I think I may have loaded the ‘TinyUSB S3’ boot loader on my nano. Could this lead to me also not being able to click the reset button twice and seeing the green light? Seems like when I was hitting the reset button twice it just kept restarting the factory loaded blink lights demo (turns on the onboard LEDs in sequence).
Indeed, if you leave a generic selection, "Upload with Programmer" will not reflash the bootloader at all. However, the guide in step 6 already says...
Go to Tools > Board and select Arduino ESP32 Boards > Arduino Nano ESP32 (or esp32 > Arduino Nano ESP32 if you’re using the full esp32 package).
(that is part of the reason I mentioned "carefully" 
)
