Pennam, is there any example of doing OTA with a binary file download and not an LZSS compressed file? I have already implemented the LZSS style OTA using the Portenta OTA code, but the LZSS encoder dylib is unreliable and slows things down anyway. So I'd rather just send the binary file but I'm not sure how to manage the file names (and magic numbers, CRC and header?) so the boot loader can perform the update.
Hi Joe,
I do not think is there any example of an uncompressed binary file ota update, but it should be easy to create one.
You can download the binary file with an http client, save it on the QSPI flash and name it UPDATE.bin
Doing in this way you should not care about crc compression and magic numbers. Once downloaded you have to write the RTC registers and trigger a board reset.
Is lzss and crc a real issue? or the problem is the dylib ? because it should be possible to create the ota binary also with the golang arduino-cloud-cli
I have created a drag&drop tool that packages up the binary file, creates the OTA file with magic number, CRC, length and uses the LZSS dylib to compress it. My tool uses CURL to automatically upload the OTA file to the proper location on my web server.
Although there were some tedious parts to making this all work, primarily silently running out of memory during the PortentaOTA download phase. I do have everything working now.
The issues are:
The dylib works fine the first time it's used. But it creates consistently different output each time it's run on exactly the same file. It seems as though its internal state is not cleared for each call to encode_file.
Because it's attempting to compress a mostly binary file the gain is not that much. My BIN is 377kB and the OTA is 303kB. So the download time savings is minimal.
However the decompression stage takes even longer than the download stage, so using a compressed file actually slows things down.
I believe the decompression saves the file to FLASH an extra time vs a straight BIN download, and so it unnecessarily increases the wear on the FLASH for no benefit.
It would be wonderful if the PortentaOTA code could handle a BIN file with the same OTA file format but just skip the LZSS decompression step.
@JoeHuber did you ever tried the decompress while downloading approach? It prevents the need to wait an extra time for file decompression because it will do it on the fly while downloading.
I had tried download and decompress on the fly back when I was debugging things but I haven’t tried it recently. I’ll try it again and compare speeds. I did get the lzss,dylib to work reliably by forcing it to unload after each call to encode_file thus ensuring a fresh reload before each call.
@pennam Thanks to your advice and encouragement I have implemented OTA updates to the GIGA using uncompressed BIN files using the HTTPClient as you suggested. Overall it seems to work fine, and I'm very happy to be rid of the dependency on the LZSS.dylb.