yes, MD5 is not important. Once we found out the problem, we recommend take MD5 checking off.
No, they are same exception.
Let us know if 1K totally working, thanks
yes, MD5 is not important. Once we found out the problem, we recommend take MD5 checking off.
No, they are same exception.
Let us know if 1K totally working, thanks
Just an update. (Sorry for the long delay, got pulled to other projects.)
The OTA update of application and firmware on an SCM20100E with extended QSPI Flash, over cellular, worked. It is painful to test since it takes 15 to 20 minutes to get the application and firmware downloaded. I am using a CAT 1 modem and I have a very weak signal.
There is much to do to build out the device app and the back-end server but the update process does work.
Thanks to everyone for their help.
Hey skeller, while of no real help at this point with OTA, are you using any compression algorithms/engine.?
I would love to see compression with ability to .zip file/folder structures.
BTW:
When we IFU apps that are say, 1MB in size over cell CAT1 LTE to SD Cardā¦it takes approx 5minā¦again no compression on the bytes and bits.
I am not using any compression. I suspect the reason for the slow download is due to the very weak signal that I have. I am inside a metal building. I think the signal is about as weak as possible but still able to connect. While sometimes a pain, it does make it a bit easier to test getting the modem and the network stack reconnected when the signal drops out.
Yeah, understand where you are coming from as far as cell testing.
We ended up building a tunable āpoor mansā anechoic chamber, which gives a pretty good āreal-world - within-a-labā experience.
ā¦of course cell has deeper inner-demons, only experienced when out in the field.
If anybody else is reading this threadā¦ideas for compression.?
This was helpful in debugging an HTTP update issue I was running into. I was trying to execute an IFU by downloading from an HTTP server and directly loading the chunks to the updater. Kept running into the generic system exception issue though. Turns out the HTTP class downloads in inconsistent chunks and were thus being loaded into the updater in various sizes causing the exception. Had to separately buffer the HTTP chunks into 1024 bytes before loading, and that seemed solve the issue. Wanted to share here for others having the same frustration. Might be worth adding an exception to the updater Loadā¦Chunk() function that prevents abnormal byte array sizes?