ESP32 Forum

- make sure I use a wrover-e module and never an older one
- flash the module in release mode
- burn UART_DOWNLOAD_DIS eFuse manually
By doing this, any attempt to flash anything would leave my partition table still intact and prevent a bricked module.

That's correct, but more correctly any attempt to flash anything will fail. If your application requires a technician to be able to flash the device over serial in the field, this will require a different approach.

Hi newhobby,

Thank you once again for letting us know about this issue.
The esptool.py bug causing it to write to flash in release mode and leaving the flash corrupted has been fixed in esptool v2.x and v3.0.

ESP-IDF (which uses esptool.py as its submodule to communicate with the ROM bootloader in Espressif chips) versions 4.2 and higher already reflect the change and checkout bugfixed esptool. The change will also be backported to older versions (including v4.1) ASAP.

If updating to a newer IDF version is not an option for you, I would recommend updating the esptool submodule manually to the latest v2.x version (https://github.com/espressif/esptool/tree/release/v2) or pulling ESP-IDF v4.1 after the backport happens.

I have used a chip Rev3 for secure boot V2 and flash encryption and indeed the download UART fuse gets burned automatically now. It doesn't allow me the brick the chip anymore.
I have another question on this though.
If I have the chip locked and OTA is the only way to get new firmware into the chip, what would happen if a firmware with a bug that would prevent the wifi connection and consequently no OTA update is ever possible again?
Is that chip forever in a state that cannot be updated anymore?
The worst would be if the OTA firmware had a bug that would somehow crash and reboot the chip. If I had thousands of product out there and this firmware with a bug was released by mistake, would I basically have 1000s of products that would need to be recalled and the chip desoldered to be usable again?

It is possible so you have to mitigate the risk to where you are comfortable using some or all of the following techniques: testing, stage new firmware rollouts to subsets of devices, use rollback with self tests, use a factory partition, have a button to trigger manual rollback or factory mode.