Yeah, I figured it out. I'm already turned on flash encryption and secure boot (right now only in development mode) and OTA updates works perfectly fine :) Thanks for advice.

Hi, I'd be happy to help. It's been a while since I configured this, but I'll share the settings I used. To install the esp32 driver software you need a configured MicroPython environment in Linux and a configured idf.py.

In bash, run the idf.py menuconfig command.

Enable Flash encryption on boot option. For testing, set Enable usage mode to Development – ​​remember, this is for testing purposes only; for full, real security, you'll need to set Release at the end. However, if you're still testing settings, selecting Development is a good option. Additionally, I also have Check Flash Encryption enabled on app startup.
If you're using NVS memory in your code, I recommend setting Enable NVS encryption to disabled in Component config -> NVS. In my case, I had problems reading data from this memory with NVS encryption on, so I decided turn it off because I don't store any sensitive data in NVS in my code.

Regarding WiFi, I currently only use it to connect to the network on my device so the controller can access the internet. However, in the initial version, the controller was set as an Access Point, and everything worked, even with flash encryption.
To enable WiFi to connect to the network, I implemented it like this:

    wlan = network.WLAN(network.STA_IF)
    wlan.active(False)
    time.sleep(2)
    wlan.active(True)

I do a wifi reset with a 2-second delay because without it the controller sometimes had connection problems.

When it comes to wifi init, I don't remember having any particular problems. If you enable flash encryption in a different way than via idf.py menuconfig, try to do it as I described - this is the safest way to set everything up correctly.

The method of flashing the software on the ESP is also important. Once you've configured everything, you build the software image using idf.py build. Then, a /build directory will be created in the /micropython/ports/esp32 directory. For flashing with flash encryption enabled, I prefer using esptool.py instead of idf.py. In the terminal, run this command from the /build directory:

esptool.py --port /dev/ttyUSB0  --chip esp32 -b 921600 --before=default_reset --after=no_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 16MB 0x1000 ./bootloader/bootloader.bin 0x10000 partition_table/partition-table.bin 0x18000 ota_data_initial.bin 0x30000 micropython.bin

IMPORTANT - you must set the flash size to the same value as the driver (usually 4/8/16 MB). Additionally, depending on the flash size and configured partition table, you must set the appropriate memory addresses. Mine are just examples, so don't copy them.

Additionally, if you're interested in Secure Boot, I'll also briefly describe how to enable it. Remember, you can only achieve full driver security by enabling both Secure Boot and Flash Encryption.

Go to Security Features and enable Hardware Secure Boot in the bootloader. For testing, you can set Secure Bootloader mode to Reflashable – this allows the bootloader to be reflashed if something goes wrong. If you set it to One-time flash, any subsequent overwriting of the bootloader after flashing the firmware will brick the processor – meaning it will be worth throwing away. I also set the Sign binaries during build option and set the Secure boot private signing key to my own key from the .pem file I generated. The key you set here is very important, and you must keep an eye on it – each subsequent application build that you want to, for example, update on the board via OTA must be signed with this key – otherwise, the board won't boot.

I hope this helps. If not, let me know. I might have some ideas on how to help you in another way. If you need more details about the OTA update, I'm also happy to help.

Hey @peetery thank you so much for taking the time to respond in such depth - I really truly appreciate it.

I had successfully gotten the ESP32 into development encryption mode previously (confirmed via fuse states, etc) but my app was crashing, wifi peripheral wasn't initializing, etc, which was confirmed via idf.py monitor. It was weirdly running the micropython app, but then crashing out in weird ways. The biggest issue though was, as I mentioned, the WiFi peripheral failing on boot, leading to cascading failures.

I had assumed this was an indication that micropython could not work properly when encryption was enabled and was giving up until I found your post and saw your success. I looked through your suggestions and workflow, and it was pretty similar to what I had done - I had enabled flash encryption, development encryption mode, check flash, etc. I did have NVS encryption enabled which was throwing some warnings on boot, so I did take your advice to leave this unencrypted to see if it would help - it did seem to have an effect, which was a great first step. This was a big insight, thank you.

I'm not sure exactly what micropython's relation to the NVS is, but it seemed like enabling encryption here was causing peripherals to fail for me. They worked properly after this was disabled.

My app was still having a few stack overflows which was weird, since the unencrypted app (simply uploaded to another board using pymakr in VSCode, which is just shuttling files to the onboard filesystem without rebuilding) had identical code and no issue. I realized it was because I had deleted the five .py files included by Micropython in the /modules directory before building. These are all minor patches that, without which, a bunch of stuff starts silently failing. Once I restored those and put my app scripts in and built, we were off to the races. No more stack overflows, app working great.

The only additional thing I learned/will mention (maybe for future folks who find this thread) is that I had a failure by my app in AP mode to serve an index.html. I realized that only .py files in /modules get compiled, any non-.py gets ignored. I was working on using a manifest.py file to fix this, but realized I don't actually want my app frozen - I would prefer it in the filesystem instead, which has to do with the way I want to do OTA. So I left /modules empty (besides the micropython scripts) and used idf.py to generate a vfs with my app files, which I was able to encrypt and flash properly, and then all was well.

The reason I bring that up in my response to you is - I'm curious how you did your OTA. My preference for having the app in the filesystem instead of frozen bytecode is because I perform OTA by simply downloading all of the new source code then replacing my old source with the new source and rebooting. I believe if my base release had the source frozen in /modules, this would still work since I think files in the file system take priority over identical module names that are frozen. But in any case, it felt safer and more intuitive to just always have the app in the filesystem.

Did you perform OTA similarly, or did you do something different, and was it informed at all by the encryption approach?

Good to know about secure-boot too - this is my next step. Sounds straightforward enough, it just signs the bootloader during build with a provided key?

MicroPython has a problem with NVS encryption, so it's best to disable it. In the idf.py menuconfig, whenever you re-enable flash encryption, NVS encryption is also enabled by default – it's worth remembering to disable it manually.

Regarding OTA updates: with the code frozen, you can also be protected and always have the application files in the device memory.
When you do idf.py build, you get 3 binary files: bootloader, partition table and micropython, and possibly a 4th file when you have a partition table prepared for OTA, i.e. the ota data intiial file. micropython.bin contains all your source code, along with any frozen modules. I have a few frozen libraries in my code besides main.py itself.

The most important thing is to have well-distributed partition table on the ESP32, and it's best to have at least 8MB of flash memory. Although it really depends on the size of your micropython.bin. In my case, 4MB of flash would be difficult. However, I have an ESP32 with 16MB of flash, so I have plenty of memory. I divide my memory so that I have 2 partitions for app code and when I upload the software for the first time, I save it on the first partition. Then, when there's an OTA update, the esp32 downloads it and stores it on the second partition. When the update downloads successfully, it changes the boot partition to the second partition and the esp32 resets. After restarting, the update is working.

Look, you now have the app code on both partitions. This allows you to even perform an OTA rollback – I've implemented this mechanism in my driver. It's simple – if the driver has already performed an update, OTA rollback allows you to change the boot partition to the previous one, thus "rolling back" the update.

When it comes to OTA and encryption, there are no problems here – at least I haven't experienced any. Just remember to test everything in the development settings or with secure boot and reflash the bootloader – if something goes wrong, you can always fix it manually.
I bricked a few processors while I was still learning how it works, so it's normal :)

Secure Boot works by signing the application image with this preset key when it's built. During boot, Esp32 checks whether the app code on the boot partition is signed with this key. If it isn't, the driver won't run, but if it is, everything will work fine.

Oh, and I almost forgot - I'm glad you managed to solve this WiFi init problem - funny that it turned out to be related to NVS encryption.