Failed to communicate with flash chip

[etech4]

Board

Custom PCB with ESP32-PICO-D4

Device Description

I have a custom PCB with an ESP32-PICO-D4 (placed by JLCPCB partnr. C193707) connected with a CP2102N-A02-GQFN24R UART bridge from SILICON LABS (JLCPCB partnr C969151).

Hardware Configuration

During troubleshooting GPIOs except IO0 have been disconnected manually on the PCB from any in or output. All are floating.

Version

latest master (checkout manually)

IDE Name

PlatformIO

Operating System

Windows 11

Flash frequency

40MHz

PSRAM enabled

no

Upload speed

115200, also tried lower

Description

When trying to communicate with the flash chip a warning about not being able to reach flash. This seems to be regardless of sketch, upload method and so on.
The behaviour is pretty much the same as in issue #7519. Sadly none of the suggested fixes have worked for my problem. GPIO 12 was connected to a status LED and was disconnected like all other GPIOs (removed resistors and so on on the PCB to let pins float). Additionally the described step of burning the efuse for the flash voltage was executed sucessfully. The message can be found in the debug section.

I have five PCBs of the same type and all of them show the same behavior. I have tried multiple computers running Windows 10 and 11 without success. I've tried connecting at different baudrates down to 19200. I've tried uploading blink examples using Ardino IDE, PlatformIO in VSCode and the espressif flash tool version 3.9.5. Also just burning the bootloader using the Arduino IDE or the espressif flash tool fails.

I've checked the power supply during the flash attemts with an oscilloscope and did not find a problem(stable at 3.36V). The PCB draws 1.17W at 24V, there are two buck converters and two LDOs (5V and 3.3V) for a stable power supply. The power consumption seems somewhat reasonable. Still, I also tried supplying 5V directly using lab bench. This did not change anything either.

Even though the UART bridge seems to be working fine, I also manually installed the newest drivers by Silicone Labs.

I understand that it is near impossible for a community member to reproduce this issue, but I'm all out of guesses and don't know how to proceed with debugging. I'm happy to try any debugging suggestions you have.

There is an interesting difference between the error message shown issue #7519 and my Debug Message 2. Manufacturer: ff and Device: ffff vs. Manufacturer: 00 and Device: 0000. Does this mean all my ESPs are just fried?

Sketch

Any blink example will do.

Debug Message

Debug Message 1: on command "esptool.py -p com9 flash_id"
esptool.py v4.7.dev1
Serial port com9
Connecting...
Failed to get PID of a device on com9, using standard reset sequence.
..
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Failed to get PID of a device on com9, using standard reset sequence.
..
Detecting chip type... ESP32
Chip is ESP32-PICO-D4 (revision v1.1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 64:b7:08:90:d7:30
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: 00
Device: 0000
Detected flash size: Unknown
Hard resetting via RTS pin...



Debug Message 2: on command "espefuse.py -p COM9 set_flash_voltage 3.3V"
espefuse.py v4.7.dev1
Connecting......
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32

=== Run "set_flash_voltage" command ===
Enable internal flash voltage regulator (VDD_SDIO) to 3.3V.

VDD_SDIO setting complete.

Check all blocks for burn...
idx, BLOCK_NAME,          Conclusion
[00] BLOCK0               is not empty
        (written ): 0x0000000401082226000004330000aab000bd64b70890d73000000000
        (to write): 0x00000000000000000001c00000000000000000000000000000000000
        (coding scheme = NONE)
.
This is an irreversible operation!
Type 'BURN' (all capitals) to continue.
BURN
BURN BLOCK0  - OK (all write block bits are set)
Reading updated efuses...
Successful



Debug Message 3: Part of the espressif flash tool log:
*************************** START ****************************
START TIME: 202310011014
CONNECT BAUD: 115200
set state: ESP_DL_SYNC
serial port opened
-----------
baud:115200
root baud:115200
-------------
===============BAUD : 115200===============CALL DEVICE SYNC
connecting...
mac l: 0x890d730
mac h: 0xbd64b7
crc_cal: 189
crc_read: 189
crc_test: 0
ESP32 MAC CRC OK
get mac res: 1
get flash id : 0x00000000
manufacturer_id: 0x0
device_id: 0x0
set STOP FLG: Trueset state: ESP_DL_STOP

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.

[me-no-dev]

This is rather really strange. The P4 has all required components already inside. You need only 3.3V power and it should work. What happens when you try to connect to the UART with 115200 baud? Do you see anything there? Obviously the chip is alive if it respond. Looks like you have provided all required power, so what is the reason is a bit beyond me.

[etech4]

The chip is silent on the UART. However, I don't understand what was ment by this comment in issue #7519. Was this the response on UART when trying to flash? How do I even read it while trying to flash?

[SuGlider]

This document may help:
https://docs.espressif.com/projects/esptool/en/latest/esp32/advanced-topics/boot-mode-selection.html

[etech4]

Thank you for the document! I tried a lot, but did not get any response. When checking the efuse status again I tumbled onto this:
CODING_SCHEME (BLOCK0) Efuse variable block length scheme = NONE (BLK1-3 len=256 bits) R/W (0b00) CONSOLE_DEBUG_DISABLE (BLOCK0) Disable ROM BASIC interpreter fallback = True R/W (0b1) DISABLE_SDIO_HOST (BLOCK0) = False R/W (0b0) DISABLE_DL_CACHE (BLOCK0) Disable flash cache in UART bootloader = False R/W (0b0)
Why is the CONSOLE_DEBUG_DISABLE set to one? Is this a default value? I can't find any good information on this in the documentation. I assume this is the debug on the UART, am I correct?
According to this documentation I can not get it back to 0. Is this correct?

[SuGlider]

Why is the CONSOLE_DEBUG_DISABLE set to one? Is this a default value? I can't find any good information on this in the documentation. I assume this is the debug on the UART, am I correct?

No. The ESP32 has a feature that when it doesn't see any flash, it drops you into a BASIC Interpreter console. We had some issues with it interrupting customers boot sequences, so I think nowadays we disable it in the ATE process. It was half an internal debugging tool, half an easter egg anyway, so it won't affect your ESP32 experience in any way.

Firmware and debug on UART are not affected.

According to this documentation I can not get it back to 0. Is this correct?

Yes, correct.

[etech4]

After getting rid of the MUN5214DW1T1G and manually pulling IO0 and IO2 low while connecting to power I got a message via UART.

waiting for download
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download 

Which I think is great. However, when trying to upload a sketch:

esptool.py v4.5.1
Serial port COM8
Connecting.....
Chip is ESP32-PICO-D4 (revision v1.1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 64:b7:08:90:d7:1c
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.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x0004bfff...
Compressed 17536 bytes to 12201...

A fatal error occurred: Packet content transfer stopped (received 8 bytes)

This happens. I've also tried to upload a bootloader.bin to 0x1000, but no success. Is there any other reason than connections to IOs that result in the failed to communicate with the flash chip warning?

[SuGlider]

I see a resistor in TxD and nothing in RxD.

My suggestion is to compare to this schematic:
https://dl.espressif.com/dl/schematics/esp32-pico-kit-v4.1_schematic.pdf

[VojtechBartoska]

Hi @etech4 , closing this as answered, feel free to reopen if needed.