I need to be able to download software updates through the internet without having my MKR1000 plugged in. Either that or have new code being pushed from my server (C++) to my MKR1000, and then rebooting with the new code. Any help is useful. Thanks.
3
-
you could use the InternalStorage object of the WiFi101OTA library to store and apply the downloaded binary– Juraj ♦Commented Jun 5, 2019 at 10:59
-
Well the goal is that i can have some MKRs spread out through the province and not have to touch them ever again, and be able to update them as necessary so the internal storage is a no-go.– Alex BoisvertCommented Jun 5, 2019 at 13:44
-
it is called InternalStorage because it stores the uploaded or downloaded binary to upper half of the flash memory. after successful upload you call apply() and it copies the binary to the run location and resets the board. new sketch is running– Juraj ♦Commented Jun 5, 2019 at 14:00
Add a comment
|
1 Answer
It may be possible if you can write your own bootloader, but it certainly won't be easy.
The normal way of doing OTA updates is to use a chip that has segmentable and remappable flash memory (such as the ESP32, ESP8266, PIC32MZ, etc) where your sketch is running from one segment, and that loads the new code from whatever source into the other segment. It then changes a single boot flag and resets the MCU, and the MCU then maps the second segment into the place of the first (swaps the two segments over) and runs the new code.
That can't be done with the SAMD21 since it has no remappable flash memory segments.
So the best you could hope for would be to reboot into a custom bootloader which then connects to the internet to download new code to flash into the main portion of the flash memory. And of course that would replace the existing bootloader and take a lot of work to create.
Addendum:
Apparently there is the "WiFi101OTA" library which allows over-the-air updates on SAMD21 boards. By all accounts this receives the new code and stores it away somewhere (a chunk of the internal flash, SD card, etc) and then copies that data to the main portion of the flash using a function running from RAM.
While this sounds good, I would not recommend using it in a live situation. For development it's fine, but not "in the field".
This is simply because there is no protection against "bricking" a unit. Once the copy from storage to main flash starts you are at the point of never being able to go back. If that write should fail for whatever reason (there is a power outage, or the sketch crashes, or any of a myriad of other unpredictable reasons) the unit is dead. You would have to manually reprogram the unit with a cable to bring it back to life.
By having the programming done by the bootloader (incidentally, some devices, such as AVR based boards, can only write to flash from the bootloader) the code that does the writing never gets overwritten, so a simple manual reset of the unit can restart the programming and recover the board.
If you were to adopt this library you would of course have to modify it to "pull" the update, not receive a "pushed" update. This should be trivial, but some level of network programming ability would be needed.
-
but the WiFi101OTA library does it. with a function in RAM, which copies the binary stored in upper part of the flash to the target location in flash. and I enhanced this library to other networking libraries and other MCU (nrf5, AVR) in the ArduinoOTA library– Juraj ♦Commented Jun 5, 2019 at 6:01
-
@Juraj I was not aware of such a library. Oh, and how does that work with AVR which can only write to flash from the bootloader segment?– MajenkoCommented Jun 5, 2019 at 7:39
-
@Juraj Also, that method is unsafe. If you start overwriting the code that is doing the programming and there is a crash or power outage the unit is bricked. With dual flash segments that can never happen since the switching of segments only happens once it's been verified the code is all written. That's why you'd want to do it from the bootloader not the main sketch, so it is possible to recover after a crash when running an ota update.– MajenkoCommented Jun 5, 2019 at 9:15
-
it doesn't brick the board. bootloader is not changed. if OTA fails, USB upload is possible. AVR ArduinoOTA needs enhanced Optiboot: github.com/jandrassy/ArduinoOTA#atmega-support– Juraj ♦Commented Jun 5, 2019 at 9:52
-
@Juraj "Bricked" means you have to manually re-upload the code through USB - something you don't want to be doing in the field. I would certainly never want to use such a thing in a live system. Anything that doesn't either use dual segment flash, or a bootloader that does the OTA work for you, is unsafe in a real environment. Development, fine. Live, hell no!– MajenkoCommented Jun 5, 2019 at 10:33