Please find my comments on the question inline:
OTA2 will not run on STMF4 devices because of insufficient RAM.
>> It does not support becaus eof insufficient RAM and flash both.
1. The RAM requirements for OTA2 is nearly 640KB.
If an example application is 256 KB, the RAM requirement is nearly 336KB. Adding OTA2 functionality to that application increases the RAM requirements to ~640KB.
2. The flash requirement for OTA2 is about 8MB. If the device do not have enough internal flash, we can use system with external flash. The internal + external flash combination should be able to fulfil the requirements for OTA2.
Can someone shed some light on why OTA2 code is consuming so much RAM? (Just to better understand the requirements and where they come from)
>> OTA2 has a much larger set of capabilites compared to OTA like being failsafe, having an extra extractor application, providing timely update(where it connects to the server and downloads the image in the background. If the downloaded image is valid, the next boot will load the newer image), etc.
What if we add external SRAM to the system? Can OTA2 make use of it?
>> If the RAM and external flash requirements are satisfied, OTA2 can be made to work. though we do not have a demo for the same.
Can one strip-down the OTA2 functionality to consume less RAM? (e.g. we do not need the SoftAP push feature)
>> You can always strip down some functionalities from OTA2 or add some in OTA to suite the needs of the application and give it a try. We have not given it a try and can not comment on the stability of the code.
I also read somewhere that only the 43907 module supports OTA2, all others support only OTA framework SW. Is this true?
>> Yes it is true. Only 43907 and 54907 supports OTA2 for now.
We use a 43438 module, does that imply that OTA2 will not work even if we meet the RAM size requirements on MCU side?
>> If memory requirements are met, theoretically OTA2 might work but again we have not tested the same.
What has the module to do with OTA2? My understanding so far is that the MCU loads the FW to the module via the dedicated interface (in our case SDIO). How does this affect the OTA2 software?
>> I am not sure about the question here. OTA is upadting the firmare over the air, it is not a replacement to load the firmware to the module.
Thanks for your answer, even though it remains unclear to me what causes the demand of such an amount of memory for this feature.
When building an app with OTA2 support the static allocated SRAM is quite low. So I assume that the 300k will be allocated at runtime from the heap. Is that correct?
Do you have more insights on what is the SRAM consumption of the different features? For example the SoftAP and OTA2 extraction feature?
1 of 1 people found this helpful
You can use mallinfo to access the free memory with different applications
extern unsigned char _heap;
extern unsigned char _eheap;
extern unsigned char *sbrk_heap_top;
volatile struct mallinfo mi = mallinfo();
wiced_log_printf("sbrk heap size: %7lu\n", (uint32_t)_eheap - (uint32_t)_heap);
wiced_log_printf("sbrk current free: %7lu \n", (uint32_t)_eheap - (uint32_t)sbrk_heap_top);
wiced_log_printf("malloc allocated: %7d\n", mi.uordblks);
wiced_log_printf("malloc free: %7d\n", mi.fordblks);
wiced_log_printf("\ntotal free memory: %7lu\n", mi.fordblks + (uint32_t)_eheap - (uint32_t)sbrk_heap_top);