It looks like the GUI download tool is a little enthusiastic in setting the flash speed/size bytes in the bootloader binary header, even when the bootloader is encrypted not plaintext. I've lodged a bug internally about this.
(esptool.py does some basic sanity checks before changing the modes, but it's safest to not pass --flash_mode and --flash_freq options when you know the image is encrypted.)
Yuriy Bohdanovsky wrote:
I used the command but the bootloader did not start
Code: Select all
$python /home/osboxes/esp/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 --port /dev/ttyUSB0 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader-encrypted_1.bin
Same error as before? Can you retry without '--flash_mode dio' and '--flash_freq 40m' options?
Yuriy Bohdanovsky wrote:I'm looking for an option to protect the firmware, but allow the user to change it through uart. I'm afraid that the user can mistakenly erase the bootloader and its device will turn into a brick.
Is it possible to block the bootloader from erasing or overwriting it?
Over UART with serial flashing, there is no protection of this kind. Depending on your use case, maybe you can provide the user with an encrypted bootloader as well (or a combined bootloader+app image binary) and have them re-flash everything over UART? This way there's no data which can be accidentally erased permanently.