esp-idf: Bricked ESP32 Modules - XMC flash chip corrupt (IDFGH-6332)
Environment
- Module or chip used: ESP32-WROVER-E (16M)
- IDF version: 3.3.5
- Build System: Make
- Compiler version: 1.22.0-97-gc752ad5d
- Operating System: Windows
- (Windows only) environment type: MSYS2 mingw32
- Power Supply: external 3.3V
Chip is ESP32-D0WD-V3 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: e0:e2:e6:4b:be:f8
Problem Description
We’ve recently gotten at least 3 bricked devices returned from customers with exactly the same symptoms. ESP module does not boot from flash. It seems to be a failure of the first-stage bootloader.
This was reported a few months ago on esp32.com but didn’t get any attention from Espressif. I then filled-out the form here a couple weeks ago: But I didn’t even get an email confirmation that it was received.
WiFive pointed out that the garbage load address 0xff001cff looks like a left-shifted version of the correct 0x3fff001c
Steps to reproduce
I’m unable to reproduce the issue in the lab. It has occurred in a small percentage ( ~ 0.1%) of units which have been sold and used by customers for up to 3 years.
Code to reproduce this issue
My application is based on this project, which includes a OTA update mechanism.
Debug Logs
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:1
load:0x3fff0018,len:4
load:0xff001cff,len:1809471
1150 mmu set 00010000, pos 00010000
1150 mmu set 00020000, pos 00020000
1150 mmu set 00030000, pos 00030000
1150 mmu set 00040000, pos 00040000
1150 mmu set 00050000, pos 00050000
1150 mmu set 00060000, pos 00060000
1150 mmu set 00070000, pos 00070000
1150 mmu set 00080000, pos 00080000
1150 mmu set 00090000, pos 00090000
1150 mmu set 000a0000, pos 000a0000
1150 mmu set 000b0000, pos 000b0000
1150 mmu set 000c0000, pos 000c0000
1150 mmu set 000d0000, pos 000d0000
1150 mmu set 000e0000, pos 000e0000
ets Jul 29 2019 12:21:46
rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Other items
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 108 (40 by maintainers)
@tvanfossen my understanding is once they are bricked, they are bricked for good.
Hi all, I’m sorry for the lack of updates on this issue from Espressif side. Thanks to everyone who posted here. This was really helpful for getting more attention to this issue! Espressif will publish an advisory on this topic.
On ESP-IDF side, there are some changes already present in IDF v4.4 (or later), v4.3.2 and v4.0.4 which greatly reduce the number of WRSR operations. More details (commit IDs) and backports to release/v4.2 and release/v4.1 will follow. These improvements are to the 2nd stage bootloader, so are applicable to new products. For the existing products, an example on how to lock the SR from the app will be provided.
In the meantime, for replacements, RMA or other business related issues, please contact sales at espressif.com.
https://github.com/espressif/esp-idf/issues/4968#issuecomment-1109895327
Hi winzkigermany, I guess @phatpaul is the right party to mention?
@vicatcu i havent tested it with other modules than the wrover-e. But if the flash chip id is the same i couldnt think of a reason this fix shouldnt work.
yes. but only if the Status Register Protection Bits have not been corrupted yet. after applying this fix none of our “unfielded” devices had this issue again:
this can also fix devices that already have this problem if SRP0 and SRP1 bits have not been set in the status register (like described above).
Any news on this? What is the proposed way to handle already delivered devices? Increase the brownout detection level to 2.8V? Write to the status register to lock it in a working state? All comments are appreciated