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.
secure boot + flash encryption in release mode [IDFGH-4332]
Re: secure boot + flash encryption in release mode [IDFGH-4332]
Re: secure boot + flash encryption in release mode [IDFGH-4332]
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.
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.
Re: secure boot + flash encryption in release mode [IDFGH-4332]
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?
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?
Re: secure boot + flash encryption in release mode [IDFGH-4332]
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.
Who is online
Users browsing this forum: ESP_Sprite and 307 guests