Is there an ESP-IDF facility for mapping executable code from a flash partition? For example, suppose I have an OTA setup: factory / OTA-1 / OTA-2. My factory image uploads new code, so the ESP32 is running from OTA-1.
Can OTA-1 code map Factory code and call functions from there? I imagine it would be similar to a shared library / DLL. Suppose I have a large computation function in the factory image, and my OTA code needs to use it. If I could map & call the version in the factory partition, I wouldn't have to send the OTA image with that code.
API to map / call one flash partition from another partition?
-
- Posts: 4
- Joined: Tue Dec 07, 2021 6:33 am
-
- Posts: 9748
- Joined: Thu Nov 26, 2015 4:08 am
Re: API to map / call one flash partition from another partition?
It certainly is possible to mmap that code. It's also possible to call functions there, however from what I recall it's not the same as loading a dll and calling that... if anything, there is no relocation of RAM variables; in other words, if there's any static variables used by the factory image, those will overlap with variables of your app and that would lead to memory corruption. The same goes for function calls within the functions you call: if you e.g. call a function that calls malloc(), the malloc() of the factory image gets called, which will possibly trash your RAM as the layout is not what it expects. Aside from that, I'm not 100% sure if an esp-idf application image is entirely position independent, so there may be absolute jumps to some code position in there that will jump to nowhere if you map the app to somewhere else than it's intended to live.
-
- Posts: 4
- Joined: Tue Dec 07, 2021 6:33 am
Re: API to map / call one flash partition from another partition?
Interesting, thanks! I tried just printing a function address from the Factory code, then calling that address from OTA code, and it didn't work at all, but that must be because the OTA code was mmap'd at the time.
It sounds like I'd have to implement all the DLL-like code: jump tables, data indirection tables and pointers into allocated RAM, etc. Maybe not worth the effort.
I'm curious, though: on a 4MB flash device, and assuming that your Factory image is about the same size as any OTA upgrades would be, aren't you limited to ~1.3MB image size (1.3MB factory, 1.3MB OTA1, 1.3MB OTA2)? I've put together a basic framework with provisioning, simple HTTP server and OTA, and I'm at 1.3MB before I do much "Application" stuff!
If I could have the Factory image handle all the basic stuff and just add "Application" code in the OTA partitions, but the Application could force re-provisioning and OTA (using call-outs to the Factory code) then I'd have much more room for Application code.
Maybe the solution is to have the OTA application set some kind of signal to the bootloader to enter Factory code on a reboot, and the Factory code can figure out that one OTA partition wanted to do an OTA upgrade or reprovision WiFi or something.
It sounds like I'd have to implement all the DLL-like code: jump tables, data indirection tables and pointers into allocated RAM, etc. Maybe not worth the effort.
I'm curious, though: on a 4MB flash device, and assuming that your Factory image is about the same size as any OTA upgrades would be, aren't you limited to ~1.3MB image size (1.3MB factory, 1.3MB OTA1, 1.3MB OTA2)? I've put together a basic framework with provisioning, simple HTTP server and OTA, and I'm at 1.3MB before I do much "Application" stuff!
If I could have the Factory image handle all the basic stuff and just add "Application" code in the OTA partitions, but the Application could force re-provisioning and OTA (using call-outs to the Factory code) then I'd have much more room for Application code.
Maybe the solution is to have the OTA application set some kind of signal to the bootloader to enter Factory code on a reboot, and the Factory code can figure out that one OTA partition wanted to do an OTA upgrade or reprovision WiFi or something.
Re: API to map / call one flash partition from another partition?
Yes 4mb can feel very small, that's why they are even putting 8mb in their newer SIPs. 2 ota, no factory is a common configuration. There is also an example of delta updates on GitHub.
Who is online
Users browsing this forum: No registered users and 84 guests