search

espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.62k stars 7.41k forks source link

Unable to flash after sketch upload - Flash error #7538

Closed megsdal closed 1 year ago

megsdal commented 1 year ago

Board

ESP32-PICO-D4

Device Description

Custom PCB - ESP32 Pico D4.

PIR sensor connected to an analog pin, and another sensor connected to I2C - few buttons on a GPIO and RGB LED

Hardware Configuration

SD0-SD3 Unconnected CMD, CLK Unconnected IO16, IO17 Unconnected IO0 only connected to programmer IO2 connected to LED Anode (But removed to test if this was the issue) IO12 (MTDI) connected with pull-down (also tested with this removed)

Using an old ESP32 Devkit C with the ESP32 module removed to flash with (connecting TX, RX, EN, IO0 GND to my module)

Version

v2.0.5

IDE Name

Arduino IDE / Espressif IDE

Operating System

Windows 10

Flash frequency

40MHz

PSRAM enabled

no

Upload speed

115200 to 921600

Description

I'm building a new revision of a prototype of a PCB with an ESP32 PICO D4 on it. In the old revision, I used an ESP32 WROOM module, but due to size issues, I had to change to PICO D4.

I had verified the hardware by running a hello world sketch and uploading it was successful.

Now it was time to upload the prototype firmware, so I changed the board type from Wroom to PICO32 and uploaded the firmware without any issue - But after the firmware was flashed, I could see the following message on the serial port: `ets Jun 8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371`

For now the device "seems bricked", since I cannot upload a new sketch / firmware. I have tried to let it autoconnect, and I have tried with the EN and boot button to flash, but I will get the following message when trying to upload a sketch: esptool.py v4.2.1 Serial port COM3 Connecting.... Chip is ESP32-PICO-D4 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e8:9f:6d:09:8e:28 Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. 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. So it seems like after flashing my previous firmware that I cannot connect to the flashchip - normally this is due to stapping pins (which is unconnected), so how can I flash a fresh bootloader when I'm not allowed to upload a sketch?

Sketch

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);

}

void loop() {
  // put your main code here, to run repeatedly:
Serial.println("Hello world!");
}

Debug Message

Sketch uses 245141 bytes (18%) of program storage space. Maximum is 1310720 bytes.
Global variables use 16440 bytes (5%) of dynamic memory, leaving 311240 bytes for local variables. Maximum is 327680 bytes.
esptool.py v4.2.1
Serial port COM3
Connecting....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:9f:6d:09:8e:28
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 17472 bytes to 12125...

A fatal error occurred: Packet content transfer stopped (received 8 bytes)
Failed uploading: uploading error: exit status 2

Other Steps to Reproduce

No response

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

me-no-dev commented 1 year ago

If you are positive that you can not upload anything on just the board (not being connected to anything else), then the issue would be bad flash, else could be something that you have connected to interfere with the bootloader. Have you tried uploading to any other board?

megsdal commented 1 year ago

If you are positive that you can not upload anything on just the board (not being connected to anything else), then the issue would be bad flash, else could be something that you have connected to interfere with the bootloader. Have you tried uploading to any other board?

Yes, I have tried 4 boards where it all works the same: Flash a basic hello world sketch or blink LED without issue Flash new prototype firmware - SPI fast boot error on COM port Try to flash basic hello world back on the board - "Failed to communicate with the flash chip" error

So there is something in my prototype firmware that messes up the flash communication / a bad bootloader - But right now I'm just trying to be able to flash a basic sketch on to the board before solving the issues in the other firmware.

me-no-dev commented 1 year ago

are you compiling that prototype firmware with the same Arduino? Generally this sounds really weird and you should always be able to flash new firmware if you manually boot into Download mode (hold IO0 while resetting with EN). BTW you can continue to hold IO0 LOW while uploading, to prevent the chip from booting out of Download Mode

Jason2866 commented 1 year ago

I would try with esptool.py to erase flash. What happens here?

megsdal commented 1 year ago

are you compiling that prototype firmware with the same Arduino? Generally this sounds really weird and you should always be able to flash new firmware if you manually boot into Download mode (hold IO0 while resetting with EN). BTW you can continue to hold IO0 LOW while uploading, to prevent the chip from booting out of Download Mode

I have no issue getting into download mode holding IO0 while resetting gives me this message on the COM port: rst:0x10 (RTCWDT_RTC_RESET),boot:0x7 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2)) waiting for download

But then when uploading I still get

'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 17472 bytes to 12125...

A fatal error occurred: Packet content transfer stopped (received 8 bytes) Failed uploading: uploading error: exit status 2

The prototype firmware was compiled with platformIO

me-no-dev commented 1 year ago

How about you continue to hold IO0 while esptool is running? Does that help? esptool sometimes resets the chip more than once during operation

megsdal commented 1 year ago

I would try with esptool.py to erase flash. What happens here?

esptool.py v3.3.2
Found 1 serial ports
Serial port COM3
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting......
Detecting chip type... ESP32
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:9f:6d:09:8e:28
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.
Erasing flash (this may take a while)...

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

How about you continue to hold IO0 while esptool is running? Does that help? esptool sometimes resets the chip more than once during operation

No change - still same error.

Jason2866 commented 1 year ago

Are you sure that strapping pins are all in the defined modes needed for flashing? Flash voltage strapping Gpio? It looks like hardware setup problem. You could set MTDI via espfuse to 0

megsdal commented 1 year ago

Hmm... I just tried with an external power supply and found a small detail that I dont know if helps - but if I power on the ESP32 from external PSU first and then plug in the USB, the error code is: rst:0x7 (TG0WDT_SYS_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 ets Jun 8 2016 00:22:57

and the system is drawing around 100mA

But If I first plug in the USB (no 3.3V connected) and then enable the PSU, then it changes to rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371 and then the system is drawing 17mA

megsdal commented 1 year ago

Are you sure that strapping pins are all in the defined modes needed for flashing? Flash voltage strapping Gpio? It looks like hardware setup problem. You could set MTDI via espfuse to 0

Right now Im working with a PCB with these pins:

SD0-SD3 Unconnected CMD, CLK Unconnected IO16, IO17 Unconnected IO0 only connected to programmer IO2 unconnected IO12 (MTDI) unconnected

Measuring IO12 / MTDI gives me 0V with an multimeter

And like I stated, I had no issue flashing the ESP32 until I uploaded that one specific prototype firmware - earlier I had no issues flashing hello world firmware.

megsdal commented 1 year ago

I have no idea how to interpret Efuses, but I took a dump if that helps:

espefuse.py v4.4
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32

=== Run "summary" command ===
EFUSE_NAME (Block) Description  = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Calibration fuses:
BLK3_PART_RESERVE (BLOCK0):                        BLOCK3 partially served for ADC calibration data   = False R/W (0b0)
ADC_VREF (BLOCK0):                                 Voltage reference calibration                      = 1114 R/W (0b00010)

Config fuses:
XPD_SDIO_FORCE (BLOCK0):                           Ignore MTDI pin (GPIO12) for VDD_SDIO on reset     = False R/W (0b0)
XPD_SDIO_REG (BLOCK0):                             If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset    = False R/W (0b0)
XPD_SDIO_TIEH (BLOCK0):                            If XPD_SDIO_FORCE & XPD_SDIO_REG                   = 1.8V R/W (0b0)
CLK8M_FREQ (BLOCK0):                               8MHz clock freq override                           = 56 R/W (0x38)
SPI_PAD_CONFIG_CLK (BLOCK0):                       Override SD_CLK pad (GPIO6/SPICLK)                 = 6 R/W (0b00110)
SPI_PAD_CONFIG_Q (BLOCK0):                         Override SD_DATA_0 pad (GPIO7/SPIQ)                = 17 R/W (0b10001)
SPI_PAD_CONFIG_D (BLOCK0):                         Override SD_DATA_1 pad (GPIO8/SPID)                = 8 R/W (0b01000)
SPI_PAD_CONFIG_HD (BLOCK0):                        Override SD_DATA_2 pad (GPIO9/SPIHD)               = 11 R/W (0b01011)
SPI_PAD_CONFIG_CS0 (BLOCK0):                       Override SD_CMD pad (GPIO11/SPICS0)                = 16 R/W (0b10000)
DISABLE_SDIO_HOST (BLOCK0):                        Disable SDIO host                                  = False R/W (0b0)

Efuse fuses:
WR_DIS (BLOCK0):                                   Efuse write disable mask                           = 0 R/W (0x0000)
RD_DIS (BLOCK0):                                   Efuse read disable mask                            = 0 R/W (0x0)
CODING_SCHEME (BLOCK0):                            Efuse variable block length scheme
   = NONE (BLK1-3 len=256 bits) R/W (0b00)
KEY_STATUS (BLOCK0):                               Usage of efuse block 3 (reserved)                  = False R/W (0b0)

Identity fuses:
MAC (BLOCK0):                                      Factory MAC Address
   = e8:9f:6d:09:8e:28 (CRC 0xc1 OK) R/W
MAC_CRC (BLOCK0):                                  CRC8 for factory MAC address                       = 193 R/W (0xc1)
CHIP_VER_REV1 (BLOCK0):                            Silicon Revision 1                                 = True R/W (0b1)
CHIP_VER_REV2 (BLOCK0):                            Silicon Revision 2                                 = False R/W (0b0)
WAFER_VERSION_MINOR (BLOCK0):                      WAFER VERSION MINOR                                = 0 R/W (0b00)
CHIP_PACKAGE (BLOCK0):                             Chip package identifier                            = 5 R/W (0b101)
CHIP_PACKAGE_4BIT (BLOCK0):                        Chip package identifier #4bit                      = 0 R/W (0b0)
MAC_VERSION (BLOCK3):                              Version of the MAC field                           = 0 R/W (0x00)
WAFER_VERSION_MAJOR (BLOCK0):                      calc WAFER VERSION MAJOR from CHIP_VER_REV1 and CH = 1 R/W (0b001)
                                                   IP_VER_REV2 and apb_ctl_date (read only)
PKG_VERSION (BLOCK0):                              calc Chip package = CHIP_PACKAGE_4BIT << 3 + CHIP_ = 5 R/W (0x5)
                                                   PACKAGE (read only)

Security fuses:
FLASH_CRYPT_CNT (BLOCK0):                          Flash encryption mode counter                      = 0 R/W (0b0000000)
UART_DOWNLOAD_DIS (BLOCK0):                        Disable UART download mode (ESP32 rev3 only)       = False R/W (0b0)
FLASH_CRYPT_CONFIG (BLOCK0):                       Flash encryption config (key tweak bits)           = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE (BLOCK0):                    Disable ROM BASIC interpreter fallback             = True R/W (0b1)
ABS_DONE_0 (BLOCK0):                               Secure boot V1 is enabled for bootloader image     = False R/W (0b0)
ABS_DONE_1 (BLOCK0):                               Secure boot V2 is enabled for bootloader image     = False R/W (0b0)
JTAG_DISABLE (BLOCK0):                             Disable JTAG                                       = False R/W (0b0)
DISABLE_DL_ENCRYPT (BLOCK0):                       Disable flash encryption in UART bootloader        = False R/W (0b0)
DISABLE_DL_DECRYPT (BLOCK0):                       Disable flash decryption in UART bootloader        = False R/W (0b0)
DISABLE_DL_CACHE (BLOCK0):                         Disable flash cache in UART bootloader             = False R/W (0b0)
BLOCK1 (BLOCK1):                                   Flash encryption key
   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK2 (BLOCK2):                                   Secure boot key
   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK3 (BLOCK3):                                   Variable Block 3
   = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Flash voltage (VDD_SDIO) determined by GPIO12 on reset
megsdal commented 1 year ago

To make sure it was not an HW issue, I bought an ESP32 PICO kit V4.

Flashing the same firmware triggers an similar result - but not completely the same. After uploading the problematic firmware to the PICO kit, then the first few messages after soft reset is:

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:12776
load:0x40080400,len:3032
entry 0x400805e4
<Info>    ESP32ADC1 - ADC ref: eFuse Vref 1��&&jY5
␓9{�C��8@�v���␆�e#�t@B��{$��$Co�H�KPQBƌ��{���l�#ets Jun  8 2016 00:22:57

Then after a few of these messages, it goes back to:

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

So there is some issue with the project that causes it to not load from the SPI.....

But a big diffrence between the PICO KIT and my custom PCB, is that I get to flash new firmware to PICO kit even after the bad firmware. So there is part SW issue, but there should also be a HW issue since I'm not allowed to flash new firmware on my custom PCB after the bad firmware.

megsdal commented 1 year ago

Latest update - I have an ESP-PROG that I have tried to use the JTAG interface to upload the "hello world" sketch on one of the bricked PCBs with no luck - it seems like the JTAG does not attach to the target successfully. 


Error: timed out while waiting for target halted
Error: xtensa_wait_algorithm: not halted 0, pc 0x40090084, ps 0x60025
Error: Failed to wait algorithm (-302)!
Error: Algorithm run failed (-302)!
Error: Too many flash mappings 10418076! Must be 2.
Warn : Failed to get flash mappings (-4)!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Failed to get flash size!
Error: Target is already running an algorithm
Error: Failed to start algorithm (-4)!
Error: Failed to get flash size!
Error: Failed to probe flash, size 0 KB
Error: auto_probe failed
Error: Failed to find bank 'esp32.cpu0.flash'!

*** [upload] Error 1
kinggiaan commented 1 year ago

I faced this problem too, and problem from my eletric circuit. When I changed on my breadboard and pinned input/output correctly to make sure no short circuit. Then my ESP32 can flash normally. -> So my problem from my circuit diagram and implementation, not from ESP32. Hope this reply can help someone.

megsdal commented 1 year ago

Success! – We found out what line in our code caused the issue.

In an old prototype before I worked on the project, the team used a second serial port for some debugging.

This ‘serial 2 begin’ line of code tried to use U2TXD and U2RXD which is IO16 & IO17.

IO16 and IO17 is used in the ESP32 PICO D4 for the internal flash for /CS and DO, where in the the old prototype with the wroom module it uses CMD and SD0 instead. So this serial port is block our access to the internal flash. Disabling this made it possible for us to flash the firmware on a new PCB

lbernstone commented 1 year ago

Even with badly behaving code in the device, you should be able to put the device into download mode by pulling down gpio0 and resetting. You can then use esptool to erase the flash, and it should be back to a state where you can flash normally. If your problem is solved, please close the issue.

Jason2866 commented 1 year ago

But a big diffrence between the PICO KIT and my custom PCB, is that I get to flash new firmware to PICO kit even after the bad firmware. So there is part SW issue, but there should also be a HW issue since I'm not allowed to flash new firmware on my custom PCB after the bad firmware.

It is solved imho. The custom PCB has a design flaw.