ESP32 Forum

Hello,

I have a hardware that has an always available MicroSD card. For updates I want to upload new binary images to the Micro SD via HTTP server (or manual copy of course).

Optimally I do not want to reserve (too much, if any) memory in flash (for OTA partition). I see the following approaches to this:

1. Create a separate, very small application partition that is booted first and only checks if there is an update on the micro sd and then proceeds to the real app. For this I wonder how to integrate compiling and flashing two applications in the make/make flash workflow.

2. Try to copy all functionality that is neccessary for reading memory from MicroSD and writing to flash into RAM and executing it, rebooting afterwards. Don't know yet if this is realistic approach with the available tools. EDIT: I saw that at least spi_flash_write has IRAM_ATTR so that side might be possible - worst case inlining all the code into it's own function.

Would be happy to hear what you think.

Best regards,

Paul

Sure, it is possible to write code that will update your code from microSD card. But you still need 2 partitions, factory + OTA or 2 x OTA, because you cant update partition you are running actual code from.
On first partition (factory or OTA) you can have only code that will download updated code from server and write it to microSD and/or write it to second partition (it depends if you want to keep copy on SD card or not). Maybe i dont see something, but there is no point to keep code in RAM except to speed up execution, but since you gonna read/write flash it will give you not much if at all any profits.

If all my instructions are executed from IRAM I don't need an additional OTA partition. For the processor it does not matter if the update code that is writing the factory partition is loaded from an OTA partition or from IRAM, it will only be a problem if functions outside of IRAM are called.

PS: Having the code in RAM will give you a decent speed improvement because you don't need to interleave read and write operations from fetching instructions and writing to flash, I pressume this is also why the spi_flash_write function has the IRAM_ATTR for example.

Like i said, no matter how you will update you have to have at least 2 partitions, but you might want to hear opinion from someone else.


PS I never thought about OTA update this way, but: @ESP_Sprite, @ESP_Angus, how about implementig OTA update functionality in bootloader triggered by gpio state on reboot? Is it possible?

You have 2 chioces:
a) invest in additional hardware (bigger flash)
b) invest in additional hardware - and software, like a small and simple MCU solution, that has the soul purpose of just reading your binary from the SD card, and writing to the ESP flash, while keeping the ESP disabled.

There is an on-going ESP ISP project here, which uses an ESP32 chip connected to the flash of another ESP32, and writing that flash for programing purposes similar to yours. For this you can just buy a ESP32-PICO-D4, which has integrated 4MB flash, the chip is about $7, and just 7x7mm size. This then can be used to interface the MicroSD, download new firmware and writing the new firmware to the ESP flash that is actually running your thing.

The purporse of two partitions (at least) is that you can be shure that you will have at least one working partition in case something goes wrong during the update (which may happen).
Even if updating the running partition could be possible, it could easily make the system unbootable if anything goes wrong during the update.

Regarding the idea to put the update code in IRAM, it could hardy be done as you should re-implement every function used in the update application to run from RAM.