Hardware Flash Corruption Issue

[Ritesh]

Just curious if your issues are related to a known issue with the flash chips manufactured by XMC?

If the output of:

Code: Select all

esptool.py flash_id

gives Manufacturer: 20,
that means you have a chip manufactured by "XMC".
And if the output of:

Code: Select all

esptool.py read_flash_status --bytes 3

gives Status value: 0xe37bfc,
that is indicative of corrupted status register.

If that's the case, head on over to:
https://github.com/espressif/esp-idf/issues/7994

Hello ESP_Sprite,

Please find following details regarding flash ID and Flash Status Register as per your request for non working board which we have received at our end.

Flash Status Register

$ python esptool.py read_flash_status --bytes 3
esptool.py v2.5.0
Found 3 serial ports
Serial port COM42
Connecting.....
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse
MAC: e0:e2:e6:4c:c7:5c
Uploading stub...
Running stub...
Stub running...
Status value: 0x600380
Hard resetting via RTS pin...

Read Flash ID

$ python esptool.py flash_id
esptool.py v2.5.0
Found 1 serial ports
Serial port COM42
Connecting...
Detecting chip type... ESP32
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse
MAC: e0:e2:e6:4c:c7:5c
Uploading stub...
Running stub...
Stub running...
Manufacturer: 20
Device: 4018
Detected flash size: 16MB
Hard resetting via RTS pin...

EFUSE Memory

$ python espefuse.py --port COM42 summary
espefuse.py v2.5.0
Connecting........_
Security fuses:
FLASH_CRYPT_CNT Flash encryption mode counter = 0 R/W (0x0)
FLASH_CRYPT_CONFIG Flash encryption config (key tweak bits) = 0 R/W (0x0)
CONSOLE_DEBUG_DISABLE Disable ROM BASIC interpreter fallback = 1 R/W (0x1)
ABS_DONE_0 secure boot enabled for bootloader = 0 R/W (0x0)
ABS_DONE_1 secure boot abstract 1 locked = 0 R/W (0x0)
JTAG_DISABLE Disable JTAG = 0 R/W (0x0)
DISABLE_DL_ENCRYPT Disable flash encryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_DECRYPT Disable flash decryption in UART bootloader = 0 R/W (0x0)
DISABLE_DL_CACHE Disable flash cache in UART bootloader = 0 R/W (0x0)
BLK1 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
BLK2 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
BLK3 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

Efuse fuses:
WR_DIS Efuse write disable mask = 0 R/W (0x0)
RD_DIS Efuse read disablemask = 0 R/W (0x0)
CODING_SCHEME Efuse variable block length scheme = 0 R/W (0x0)
KEY_STATUS Usage of efuse block 3 (reserved) = 0 R/W (0x0)

Config fuses:
XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset = 0 R/W (0x0)
XPD_SDIO_REG If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 0 R/W (0x0)
XPD_SDIO_TIEH If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 0 R/W (0x0)
SPI_PAD_CONFIG_CLK Override SD_CLK pad (GPIO6/SPICLK) = 0 R/W (0x0)
SPI_PAD_CONFIG_Q Override SD_DATA_0 pad (GPIO7/SPIQ) = 0 R/W (0x0)
SPI_PAD_CONFIG_D Override SD_DATA_1 pad (GPIO8/SPID) = 0 R/W (0x0)
SPI_PAD_CONFIG_HD Override SD_DATA_2 pad (GPIO9/SPIHD) = 0 R/W (0x0)
SPI_PAD_CONFIG_CS0 Override SD_CMD pad (GPIO11/SPICS0) = 0 R/W (0x0)
DISABLE_SDIO_HOST Disable SDIO host = 0 R/W (0x0)

Identity fuses:
MAC MAC Address
= e0:e2:e6:4c:c7:5c (CRC 18 OK) R/W
CHIP_VER_REV1 Silicon Revision 1 = 1 R/W (0x1)
CHIP_VERSION Reserved for future chip versions = 2 R/W (0x2)
CHIP_PACKAGE Chip package identifier = 1 R/W (0x1)

Calibration fuses:
BLK3_PART_RESERVE BLOCK3 partially served for ADC calibration data = 0 R/W (0x0)
ADC_VREF Voltage reference calibration = 1135 R/W (0x5)

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

Also find attached boot up logs for non working board which we have received at our end.

Let me know if need anything else from my end

[Ritesh]

Hello ESP_Sprite,

Let me know if need anything else from my end regarding issue details? I have already provided required details from my end for board which is not working.

[Ritesh]

Hello ESP_Sprite and Developers,

Is there any updates from your end? I have already provided enough details from my end which you need at your end.

Let me know if need anything else from my end.

[Ritesh]

Hello ESP_Sprite and Developers,

Is there any updates from your end? I have already provided enough details from my end which you need at your end.

Let me know if need anything else from my end.

[Ritesh]

Hello Espressif Team,

We have checked again Firmware File and Firmware Contents stored into Flash location and found that one bit is corrupted in between due to which overall checksum is failed.

But, We don't have any idea like how bit is going to change of firmware stored into flash location?

Anyone has idea like Flash Memory lot is not proper or kind of any other guess?

[ESP_Sprite]

Where is this bit located and how did it get corrupted (as in: what is supposed to be there and what did you read there)?

[Ritesh]

Where is this bit located and how did it get corrupted (as in: what is supposed to be there and what did you read there)?

Hello ESP_Sprite,

We have checked and compared each and every byte of stored firmware and firmware file which we have flashed in which we have found at one location where one single bit has been changed from 1 to 0

Please find attachment for the same

We don't know that how it is has been changed on site which we have to find out.

[Ritesh]

Hello ESP_Sprite,

We have received following updates from Espressif Sales Team regarding issue which may be solution for us.

Dear Ritesh,

Thanks for your information.

For the issue you encountered, we speculate that in the process of frequent power-on and power-off, the flash may be under abnormal working voltage for a long time and disturbed by the power supply jitter, disordered instructions on the data line may cause the flash to operate incorrectly, which caused the bit transition.

This issue has been fixed on esp-idf master branch, and the fix commit is 6a2d3509dcedc2fe67a98ae3a0fd5a089c256ef8.
https://github.com/espressif/esp-idf/co ... 089c256ef8

The fix uses the built-in brownout detector to monitor the external power supply voltage, it will send a command to stop the flash operation in time to avoid flash misoperation when a power failure is detected. It is recommended to test and verify after applying the fix.

From the log output of your device, I find that esp-idf version you are using is v3.1-beta1-216-gd91c425178-dirty, please note that v3.1 is already EOL.
Please see ESP-IDF Support Period Policy.
https://github.com/espressif/esp-idf/bl ... _POLICY.md

I have checked with our internal team, we may not backport this fix to esp-idf v3.1, will you upgrade the IDF version to the master branch? It would be a big challenge for you cause there are many changes between v3.1 and the master branch.

But, We don't have any option to port our application over Master Branch as Product is already deployed over site and we have only OTA support and also lot more testing and porting time is required to move into Master Branch.

So, We need to find out particular patch or changes into current IDF 3.1 in which issue can be resolved.

Let me know if you have any other feedback from your end

[ESP_Sprite]

The mail actually refers to the commit which changes the behaviour. You can backport that to your ESP-IDF version.

[Ritesh]

The mail actually refers to the commit which changes the behaviour. You can backport that to your ESP-IDF version.

Hello ESP_Sprite,

I have checked changes from top and it seems like difficult to back port those changes into ESP32 IDF Version which we are using. Because those changes are made over ESP32 IDF Version 5.0 while we are using ESP32 IDF Version 3.1 as per our application requirements at that time.

If you have any suggestions or clue like how it can be back ported those changes into ESP32 IDF version which we are using and that would be really appriciated.