Flashing of firmware fails in Esp32 Wroom 32D

[PreetiN]

Development Kit: [ESP32-DevKitC]
Module or chip used: [ESP32-WROOM-32D]
Operating System: [Windows]
Using an IDE?: [Yes.Visual Studio Code]
Extensions used in Visual Studio Code: Platformio IDE V1.10.0, C/C++ V1.4.0
Power Supply: [external 5V]

Hello,
We are facing issues while burning the Firmware into the ESP32-WROOM-32D microcontroller. The Firmware got burned
successfully into 195 such devices containing ESP32-WROOM-32D microcontroller but failed in the remaining 5 devices
containing identical hardware and same flashing mechanism.

The Error we got is as follows:
RAM: [== ] 15.1% (used 49464 bytes from 327680 bytes)
Flash: [======== ] 78.1% (used 1228970 bytes from 1572864 bytes)
Configuring upload protocol...
AVAILABLE: esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Auto-detected: COM6
Uploading .pio\build\esp32dev\firmware.bin
esptool.py v2.6
Serial port COM6
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
*** [upload] Error 2
====================================================================================== [FAILED] Took 35.97 seconds ======================================================================================The terminal process "C:\Users\pc\.platformio\penv\Scripts\platformio.exe 'run', '--target', 'upload'" terminated with exit code: 1.

Terminal will be reused by tasks, press any key to close it.

There was no shorting of pins in those 5 devices even the ESP32-WROOM-32D microcontroller was checked thoroughly for shorting.

Surprisingly, the issue was resolved when the ESP32-WROOM-32D microcontroller was replaced by another one in those 5 devices.

The flashing is done by pressing the EN button momentarily(ESP is reset) while holding down the IO0 button. So now the ESP32 will successfully enter the flash programming mode.

The flashing of Esp32 is done using switches S1(Enable) and S2(IO0) as shown in the schematic below. Also the header P7 is used
where CP2102 USB 2.0 to TTL UART Serial convertor is used for flashing firmware into the Esp32.

Any help will be appreciated.

[ESP_Sprite]

Hm, I can't see anything funky in your schematic... the 470 ohm resistors in series with the buttons certainly wouldn't be something I would do, but I don't think they are an issue here.

Can you connect a serial terminal program to the serial port and see what the ESP32 sends on reset, with or without IO0 pulled down?

Also, have you inspected the soldering on those chips? While you may not have a short, a dry joint could lead to an intermittent connection, breaking the flashing process.

[PreetiN]

Hi @ESP_Sprite, answering your query regarding the dry joint, we eliminated that possibility by resoldering that particular
ESP32-WROOM-32D microcontroller on a working device, but the firmware couldn't get burned into it.

As suggested by you, on pressing reset without the IO0 pulled down, the Serial monitor didn't show error messages(Please note
that the ESP32-WROOM-32D microcontroller still doesn't have any firmware burned into it.)

But in the remaining 195 devices when the flash is totally erased(meaning no firmware in it at all) and on pressing reset without
the IO0 pulled down we get the following error messages:
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57


What could be the reason for it?
Any help will be highly appreciated.

[ESP_Sprite]

Okay, no bootup message means either that GPIO15 is connected to ground (unlikely to be the problem as that would not prevent you from flashing the device) or the ESP32 module itself is not booting at all for some reason. As this bootup message is emitted by ROM, it's not dependent on anything put in flash. Suggest you take a very good look at the EN, Gnd and Vcc pins of the Wroom module, see if the voltage levels there are OK, see if the module is reset correctly. Possibly try changing R48 for a wire link or 0 ohm resistor as well, see what happens if you press reset with that.

[PreetiN]

Hi @ESP_Sprite,
Tried with R48 as 0 ohms but still couldn't get any bootup messages on the Serial Monitor after pressing reset.
On checking the VCC and GND pins of this Esp32 microcontroller, we obtained 3.3V and 0V respectively.
Doesn't look like the GPIO15 is grounded in our case.
What else could be the reason?

We would be going for mass production of devices soon.

Any help would be useful for us.

[ESP_Sprite]

I have no clue, sorry. If you haven't tried, the last thing you could look at is to see if the EN signal comes through cleanly, but otherwise I don't know. Fwiw, something did happen at some point because a 2.5% failure rate is pretty large.