Flash read error when flash encryption is enabled

[GerryTitan]

Hi,

I am trying to understand how the flash encryption procedure works. I am using ESP-IDF version 4.4, and I have an ESP-WROOM-32 development board.

After I enabled flash encryption (development mode) in the menuconfig and disabled NVS encryption (and increased the partition table offset to 0x10000), I built and flashed the bootloader and firmware to the ESP32. I waited a few minutes and then entered the monitor mode. When I did this, I received the "flash read err" indicating that the ROM failed to read the bootloader. I figured maybe the encryption process just got interrupted, and the bootloader was left in a corrupt state (i.e., partially plaintext, partially encrypted).

Here is where it gets slightly weird. I checked the eFuses configuration, and the following eFuses were set: FLASH_CRYPT_CONFIG, JTAG_DISABLE, DISABLE_DL_DECRYPT, DISABLE_DL_CACHE, and BLOCK1 (flash encryption key). Notably, FLASH_CRYPT_CNT was not set, as it still had value 0. So I thought this meant that I could re-upload the plaintext bootloader, which would again attempt to encrypt each partition. However, no matter how many times I re-upload the bootloader, I always see the flash read err!

The only way I have solved this problem is to manually increment FLASH_CRYPT_CNT to 0b1, and use "idf.py encrypted-flash" to encrypt the partitions at flash-time. When I do this, everything works perfectly.

Does anybody know what might be going wrong here? Thanks.

[ESP_Mahavir]

Hi @GerryTitan,

If FLASH_CRYPT_CNT is not set, i.e., all bits are 0 then flash encryption is not enabled on the device. So ideally, plain text (2nd stage) bootloader should work fine.

Can you please specify steps you followed to enable flash encryption on device? Also please specify espefuse summary that you get using command `espefuse.py --chip esp32 summary`?

Just to note: `esptool` performs reset on device once its operation (program) is complete (https://docs.espressif.com/projects/esp ... eset-modes). This can be avoided by adding `--after no_reset` argument. This way its easier to control and monitor actual bootup sequence.

Thanks.