ESP32-WROOM first stage bootloader failure

[phatpaul]

I haven't gotten any response from Espressif.

I also filled-out the form here a couple weeks ago: https://www.espressif.com/en/contact-us ... bug-report
But I didn't even get an email confirmation that it was received.

I guess the next step is to open a ticket on Github to try and get some attention?

EDIT: I opened a ticket on esp-idf https://github.com/espressif/esp-idf/issues/7994

[nedrysoft]

I'm seeing this problem, interestingly on an E device which seems to be the same as the other posters here.

I have.4 devices under test, they wake up every 30 minutes from deep sleep, connect to wifi, publish their data, go back to sleep.

3 are still working.
1 died within 12 hours.

The dead one I hooked up to USB and it was constantly spewing out a boot loop from the first stage bootloader.

Code: Select all

ets Jul 29 2019 12:21:46

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, 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:7084
ho 0 tail 12 room 4
load:0x07800000,len:3662912
ets Jul 29 2019 12:21:46

Like the OP, there appears to be a shift of 1 byte, on a working unit I see this:

Code: Select all

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, 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:7084
ho 0 tail 12 room 4
load:0x40078000,len:14308
load:0x40080400,len:3716
0x40080400: _init at ??:?

entry 0x40080680
I (29) boot: ESP-IDF v4.3-194-g5b5e46971a-dirty 2nd stage bootloader

Note, the second load: starts with 0x40, this 0x40 is missing from the dead board.

The length of "0x40078000" is 0x0037E4 (Alive)
The length of "0x07800000" is 0x37E440 (Dead)

Here you can see that the 0x40 that is missing from the address, is appearing in the length.

So this all lines up with the other posters, somebody the first stage bootloader now appears to have a 1 byte offset, but, the first load (0x3fff0030) is correct in both the dead and alive.

It never gets to the point of the third load on the dead board, it resets somewhere after "load:0x07800000,len:3662912".

I have verified the flash content against the binaries.

Code: Select all

esptool.py verify_flash --diff yes 0x1000 build/bootloader/bootloader.bin

esptool.py v3.1-dev
Found 5 serial ports
Serial port /dev/cu.wchusbserial1450
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 34:ab:95:47:29:18
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Verifying 0x6270 (25200) bytes @ 0x00001000 in flash against build/bootloader/bootloader.bin...
-- verify OK (digest matched)
Hard resetting via RTS pin...

esptool.py verify_flash --diff yes 0x10000 build/hugh.bin

esptool.py v3.1-dev
Found 5 serial ports
Serial port /dev/cu.wchusbserial1450
Connecting.......
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 34:ab:95:47:29:18
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Verifying 0xeda20 (973344) bytes @ 0x00010000 in flash against build/hugh.bin...
-- verify OK (digest matched)
Hard resetting via RTS pin...

esptool.py verify_flash --diff yes 0x8000  build/partition_table/partition-table.bin

esptool.py v3.1-dev
Found 5 serial ports
Serial port /dev/cu.wchusbserial1450
Connecting......
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 34:ab:95:47:29:18
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Verifying 0xc00 (3072) bytes @ 0x00008000 in flash against build/partition_table/partition-table.bin...
-- verify OK (digest matched)
Hard resetting via RTS pin...

the flash status:

Code: Select all

esptool.py read_flash_status
 
esptool.py v3.1-dev
Found 5 serial ports
Serial port /dev/cu.wchusbserial1450
Connecting......
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 34:ab:95:47:29:18
Uploading stub...
Running stub...
Stub running...
Status value: 0x7bfc
Hard resetting via RTS pin...

and flash id:

Code: Select all

esptool.py flash_id     
    
esptool.py v3.1-dev
Found 5 serial ports
Serial port /dev/cu.wchusbserial1450
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 34:ab:95:47:29:18
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4018
Detected flash size: 16MB
Hard resetting via RTS pin...

I have spent all day trying to resolve this, but I'm utterly stuck now, it was working fine and overnight it failed without any interactions, once I noticed it was not sending telemetry was the point I plugged it into USB and found it had got into this state.

At this point now I'm considering my options on how to remove this module from my board, which is probably going to be destructive to the ESP32.

Anybody resolve this? Any ideas?

[m.gigante]

Hello, did somebody find any workaround or recovery procedure for this. I have the same problem on some board on the field and I must recall and replace them.

[phatpaul]

People, check the ticket on esp-idf https://github.com/espressif/esp-idf/issues/7994

TLDR;

• Several ESP32 modules are built with flash chips from manufacturer "XMC"
• These are susceptible to corruption of the status bits. Vcc brownout is likely the cause. The brownout detector doesn't help.
• If the status bits become corrupted, THERE IS NO WAY TO RECOVER IT. The flash chip is "Bricked" and must be replaced.
• The only hope is to prevent the corruption by setting the status to a good value and setting a Write Protect bit to keep it that way.
• This can be done with a programming script at your assembly time, or with some code in an application OTA update. But the latter is difficult due to ESP32 flash cache.
• Still no official fix as of now, but igrr has promised a workaround will be provided.

[lordzyx]

******* SOLVED *******

If anyone still struggling with this error..
Today it happens to my LILYGO A7670E ESP32 board.

I fixed.

Used online ESPTool (https://espressif.github.io/esptool-js/) and fully erased the chip.
Next, I flashed it with original firwmare.

Fully working now.