ESP32 Forum

HI,

I bought a ESP32-S3-DevKitC-1-N32R8V board (https://hu.mouser.com/ProductDetail/356 ... KTC1N32R8V) and try to upload a simple program to it with Arduino ide but got the A fatal error occurred: Failed to connect to ESP32-S3: No serial data received.

I tried the ESP32S3 Dev Module and the ESP32S3 Dev Module Octal (WROOM2). I tried both available ports (even I relocated to another USB) but I always get the error message above. I connected the board to PC via USB port (it has an UART too) The cable is good quality. I don't know what else I can try.
Which board should I choose in arduino?

Use the UART plug on the board.
https://docs.espressif.com/projects/ard ... -my-sketch
Most likely is a bad cable or missing driver.

I bought a ESP32-S3-DevKitC-1-N32R8V board (https://hu.mouser.com/ProductDetail/356 ... KTC1N32R8V) and try to upload a simple program to it with Arduino ide but got the A fatal error occurred: Failed to connect to ESP32-S3: No serial data received.

have you finally managed with your ESP32 boards?

it's very interesting question: if i bricked arduino ESP32 by destroying it's bootloader, which hardware do i need and what should i do to unbrick it back?
with AVRs it's never a question, since there are lots of programmers able to flash arduino bootloader to AVR MCU back, even simple hand-made ones. moreover, i never use available AVR-based arduino boards as "arduinos", since it costs almost nothing to switch to pure C and in-circuit flashing with e.g. cheap USBASP.

well, when there is a 25QXX SOIC-8 flash chip on the ESP32 board(have some boards like this), it can be overwritten with tons of hand made programmers or ones like USBASP, and most likely in-circuit, without welding out.
in case bootloader resides in ESP32 MCU flash, a JTAG adapter could be the magic pill...

it's very interesting question: if i bricked arduino ESP32 by destroying it's bootloader, which hardware do i need and what should i do to unbrick it back?

If you managed to destroy the bootloader, there is absolutely no way to get it back. However, I think you'll find it is nigh impossible to destroy the bootloader: it is in actual read-only memory, encoded in the metal layer of the design of the chip; destroying it would involve either physically destroying the ESP32 chip itself, or decapping it and going in with a focused ion beam (which I assume you probably won't have in your toolbox). As long as you're just programming it (and as long as you're not touching the eFuses or somehow physically damage the ESP32) you should always be able to get it back to normal.

yesterday my friend "bricked" two WeMos Lite boards:
even if MCUs was functioning, they became unable to be flashed with all the arduino stuff. he attached a 5V ADC to some pins including D0, which acts as startup-critical BOOT option. he thought he could destroy pin D0 by overvoltage, so there is no way to use these boards in arduino way any more.

attempts to talk to these bricks with some UART-logging java program, uploading stubs bootloader and dumping a little piece of flash with it sometimes was successful on one of boards - when playing around with RST button during UART software reset sequences.

digging deeper with a multimeter showed, that DO pin resistance against 3V3 and GND wires in both directions is almost the same as on board he hadn't bricked yet - protection diodes and push/pull cascade are alive. moreover, voltage of D0 at power-on reaches ~0.4V on all boards and falls down after a while on "bricked" ones(btw, why the huck it rises up to 0.4V but not up to 3V3, as e.g. on DevKit V1 and so on - even with a 470R pull-up?!!), while on functional board it remains 0.4V forever.

so, we got some room to hope the hardware survived 5V torture and we're actually facing a troublesome, but software issue. fortunately, the program flash IC - 25Q32ESTIG - on these pieces of WeMos crap resides in the open air - we can connect it, try erasing and see if it helps.

and let me introduce my hero:
even if it isn't aware of exactly 25Q32, fails to read it's ID registers correctly and shows kind of stable ID values only at lowest SPI IO frequence, it turned out that enforcing "Unprotect" -> "Chip erase" breathed a second life into these pieces of WeMos crap: both "bricked" boards stable enter bootloader mode now and are successfully detected by ESP FlashDownloadTools 3.6.7.

what is the moral of this story?

at first, looks like WeMos Lite BOOT option circuit is as suxy-by-design(no button for user to control it and extremely low voltage level, even with strong external pull-up) as it can be bricked by software, altering D0 function.

at second, the arduino way has its downside - loss of control. without simple, basic level tools, like e.g. this one(which saved me many times when serial memory related issues happened and is a workhorse at dealing with AVR MCUs):
(open source and can be assembled using not so expensive or even scrap ICs)

so, the story... when arduino way fails for some reason, without basic tools like these you just suck.
and the thing is with these basic tools you not only don't suck - you control the situation as much as you don't need this "arduino way" at all!(thanks to USBASP all my AVR arduinos are "downgraded" into simple development boards, equipped with USB-UART hardware)

and finally: would be great if platform designers respect this approach too, not only focus on this arduino ideology.