Failed to communicate with the flash Chip

[arslan437]

Board

Esp32 Wrover-E

Device Description

Custom PCB With schematic shown in the picture below

Hardware Configuration

Attached the schematic above

Version

v2.0.5

IDE Name

Platformio

Operating System

Windows 11

Flash frequency

40MHz

PSRAM enabled

no

Upload speed

115200

Description

I tried to get the flash details via this command

esptool.py -p com5 flash_id 

got this result

esptool.py v4.4
Serial port com5
Connecting...
Failed to get PID of a device on com5, using standard reset sequence.
.
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Failed to get PID of a device on com5, using standard reset sequence.

Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 94:e6:86:a8:34:04
Uploading stub...
Running stub...
Stub running...
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Manufacturer: ff
Device: ffff
Detected flash size: Unknown
Hard resetting via RTS pin...

get the same results when trying to upload the code

Sketch

Unable to upload code

Debug Message

Already addded above

Other Steps to Reproduce

No response

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

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

[arslan437]

if the device is not in upload mode then its printing this on the serial monitor.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
ets Jul 29 2019 12:21:46

[Jason2866]

Looks like a defect module. Nothing which can be solved with soctware.

[lbernstone]

Note that you are getting a boot:0x33, which implies that gpio12 is pulled up. If you cannot guarantee that it is low at boot, burn the efuse to lock it.

[T1j3ff]

Got similar issue on a custom PCB, I use io12 on a periferal like you , I can program my ESP if I unconect this pin ... This seems to be one pin of the dataline for the SPI flash chip .. Still investigating

[arslan437]

Thanks everyone for providing the info. I have connected the PIR sensor with gpio12 pin. That was pulling the pin high. Which changed the voltage level for on board SPI flash.

By removing the PIR sensor I am able to get module working.

[TD-er]

You should only use GPIO-12 as an output pin. Or at least it should never be pulled up or down by something external.
The state of this pin will determine the flash voltage.
If you have a board which needs the lower voltage of both options, you will fry the chip.
For the other option, it will just "not work"

[lbernstone]

The OP issue is about a module. ESP32 modules should be using discrete 3V3 flash (some pico chips will have internal flash), so it will not "fry" anything by burning the efuse, fixing the voltage at 3V3.

[Frozen-Burrito]

I know this issue is already closed, but it helped me solve the problem and I would like to share my experience in case someone finds it useful in the future.

The option mentioned by @lbernstone worked perfectly for me. For my project, I designed a custom board with an ESP32 module and I was getting the same output shown in OP when trying to flash my application. It turns out that I used GPIO12 for an I2C SDA line with external pull-up resistors in my board, so the pad was always high during boot. I solved this by using this esptool command to burn the efuse bits for 3.3V flash (VDD_SDIO) voltage selection. After doing this, I was able to flash my application and still use GPIO12 as a "regular" GPIO for my I2C bus.

I agree that you should not use GPIO12 (or any other bootstrap pins) if you have another option, and that you should first try disconnecting any device that could be pulling the pad high at boot, as @arslan437 did. If you can't do any of these for some reason and you are 100% sure that the problem is related to flash voltage selection, I do recommend reading section 7 "Part Number and Ordering Information" of the ESP32 datasheet to find out the flash voltage used by your ESP32 module, just to be sure that you are burning the correct configuration in efuse.

[etech4]

Hi, I also know this issue is closed. However, opening another issue directly continuing this one seems a little odd to me.

I have the exact same issue and tried all steps mentioned above without success. I've tried it on multiple (also custom made PCB) with all GPIOs disconnected and had no success. The burning of the efuse to fix 3.3V flash voltage can be executed succesfully but did not fix the problem. The "WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs." message is still there whenever trying to communicate with the flash chip.

Any ideas on how I could continue debugging are warmly welcome. Also, should I open another issue if the problem percists or is there a way to reopen this issue?

[aman9302]

You should only use GPIO-12 as an output pin. Or at least it should never be pulled up or down by something external. The state of this pin will determine the flash voltage. If you have a board which needs the lower voltage of both options, you will fry the chip. For the other option, it will just "not work"

Thank you so much for this.