Previously working board, suddenly goes "A fatal error occurred: Active security features detected"

[jesper]

We have a few thousand ESP32-U4WDH based boards out with customers and recently got one back that had entered some kind of loop and drained batteries.
When testing, there is NO data on the serial channel.
Trying to re-flash the firmware worked fine, but, still no log.
We then tried do an 'erase_all' and got this message: "A fatal error occurred: Active security features detected, erasing flash is disabled as a safety measure. Use --force to override, please use with caution, otherwise it may brick your device!"
We tried using --force and the erase_flash command succeeded.
Then we re-flashed the firmware, but still nothing on the log.
The board clearly doesn't start at all, LEDs are dead too.

The board have been working for several days / weeks.

What could possibly cause the ESP32 so suddenly go into a state like this?

[ESP_adokitkat]

Hello.

What ESP-IDF version are you using?
What is the program flashed on the ESP32 doing?
Does it use secure boot and/or flash encryption?
Does the code perform any IO operations on the SPI flash memory?
Does it use NVS or any other file-system partition? \

Did you try to flash another example project (like `blink`) to see if the board is working at all?

[jesper]

We're using ESP-IDF 5.2.1
This is ONE board out of a batch of 5000 that is all ok.
It was extensively tested before delivery and has been working fine in the field for some time.
We do not use ANY security features like Secure Boot, Flash Encryption or anything.

It complains when doing the erase_flash. Using --force make it erase, but trying without --force afterwards still complains.
Code downloads fine, but does not run.
The UART is silent, except when using BOOT button to go into bootloader mode, then the usual "waiting for download" message are printed. Nothing is printed if the board is reset or powered up.

Checking efuses with espefuse.py, reveals the FLASH_CRYPT_CNT is set to 1, which seems to be the cause of the problem.
Why this also cause the UART to go silent in app mode is odd, it should at least print the initial boot message "ets Jul 29 2019 12:21:46"
This has NOT been set from the application or in the initial flash programming in any way. It has happened out in the field in some way.
ALL other efuses are as original.
Apart from the MAC address that obiously differ, the undocumented, reserved field, at EFUSE_BLK0_RDATA4_REG (0x010), bits 8-13 are 0x04, but seems to be different/random on all boards I have looked at.

We do NOT do any specific flash IO, but use the NVS (as there is WiFi support) and also for configuration storage, an approx 170 byte storage blob, using the nvs_* functions.

Brown out reset is active, as we might get BO in certain situations.

/Jesper

[ESP_adokitkat]

eFuses spontaneously changing their value is unlikely but possible (and irreversible). FLASH_CRYPT_CNT being a very specific eFuse as well, if someone didn't tamper with the device then it's really "(un?)lucky" to have this specific one change it's value.

Anyway, with FLASH_CRYPT_CNT having an odd number of bites burnt, ESP32 behaves like flash encryption is enabled. https://docs.espressif.com/projects/esp ... -cnt-efuse

You can however still change this behavior burning one more bit so an even number of bits is burnt and this will disable the flash encryption. This is limited to 7 bits, after all 7 bits are burnt you the flash encryption cannot be disabled at all - please read the docs page linked above.

If FLASH_CRYPT_CNT value is 1 right now (0b0000001), you can use espefuse.py to burn another bit so the flash encryption will be disabled:

espefuse.py burn_efuse FLASH_CRYPT_CNT 3

3 because 0b0000011, 2 bits are burnt. Then you can re-flash your original firmware.

You can also contact us directly via sales channel and this can be handled via the RMA process.

[jesper]

Thank you,
I'm aware of how the FLASH_CRYPT_CNT works and how to "fix" this by adding a bit, but I don't care about saving a board.

I want to know HOW and WHY this happened, so we can (if possible) make sure it doesn't happen again.
The fact that it's only this single bit that has been changed in the eFuse blocks is odd, if a spurious write happened, I would have expected more bits to be flipped, one way or the other.

Is the FLASH_CRYPT_CNT bit the reason why there is absolutely ZERO output from the device when it's reset? I would at least expect the first boot header and an error message. But there is NOTHING.

Any light you can shed on the reason on why this occurred will be very much appreciated.

/Jesper