You have been so helpful in the past, I just had to run this one by you.  It is certainly something that I have never seen in the past.

I have designed a board with an ESP32-S3 that uses a TFT display.  I built up three and they all run great.  As expected, when the ESP32 first comes up, it goes into this loop that opens and closes the USB Com port.  The board does have the EN and BOOT buttons and so I use them to put the ESP32 into a stable upload mode.  Once programmed for the first time, it is smooth sailing from then on.

Here is the bizzare part.  I attempted to build two more but when I went to program the ESP32, the Com port goes away.  The loader says that it does not exist.  It is when the uploader is attempting to open the port, not do the actual uploading.  No amount of powering the board up and down will bring it back. This happened with both of the boards I attempted to program today.

Attached is the schematic.

Uploading 'DMXDisplay' to 'ESP32S3 Dev Module(esp32_esp32s3)' using 'COM15'
esptool.py v4.5.1
Serial port COM15
esptool.py v4.5.1
Serial port COM15

The uploader returned an error
A fatal error occurred: Could not open COM15, the port doesn't exist

Thanks, can you also enable vMicro > Compiler > Show Build Properties (this should have been enabled when selecting vMicro > Compiler > Verbose), and re-attach the log?

Can you email it to info at visualmicro.com, and we will attach it to the post.

Sometimes you need to go back to the main board, then navigate to the thread for the file attachment to show up, which we are looking into.

This is so very weird.  I designed this v1 version of this board and had the usual first time annoyances but that was mostly associated with have in the right ESP32 core installed.  (You guys helped me through that.)  The first design worked great.

I then re-laid out the board for just better physical location of some components.  The design was the same.  I build up three v2 versions and it all went great.  There is a companion board that the display board talks to and both versions of the display board work with the companion board.  It is just these latest two that have this program.  What can change in just 24 hours!

I am relucatant to build more if I am somehow blowing up the ESP32s.

They program just fine.

Thanks for confirming the details.

So as the v1 boards still program with the same code/board package/board settings, but the new boards don't, it feels to be a problem with the new hardware design (trace lengths or components on the reset circuitry may be worth reviewing from your latest description).

I was able to resurrect one of these latest two but not the other.  The traces and other aspects of the design are the same.  I just moved the EN and BOOT buttons to a different place.  The reason for the change was mostly part number changes and labeling.  They are very hard to tell apart.

I don't think the key is the board.  The first three of the new design programmed just fine although I did have to run the LittleFS example first.  I skipped that step with the second two.  If it was needed, I would have gottne the LittleFS failure.  I didn't even get to that part.  Once the uploader tried to open the COM port, the port vanished.  Of these two boards, I was able to get its COM port to appear again.  I then loaded the LittleFS example, and then my program, and it is all working fine.  I have not been able to do that with the second of these two.

Close.  The first three of v2 were eventually programmed successfully.  The next two did not.  One of those was able to have the COM port recognized and programmed successfully.  So four out of the five are fine.  All were programmed with exactly the same compiler settings and libraries.  All have ESP32s from the same batch that I ordered.  (I suppose some could be different within the order I received.)  It is possible that the fifth one may have some assembly error but I am quite skilled in this area.  But yeah, it could happen.