OTA update/reprogramming

Has any thought been given to an over-the-air update mechanism for RIOT based devices?

Thanks.

–adam

Hi Adam,

I don't speak officially but I'm sure that it would have been considered.

One challenge is the number of different boards that are currently supported. And writing a bootloading protocol for all the different boards would be a rather time consuming I'd think.

A better way in the IoT world is to preload the machine with a 'swiss-army-knife' controller. That can turn pins on and off and transmit ADC/Pin values and so forth depending on packets received.

Quite a few people have written them but here's mine from my side project: https://github.com/clixx-io/clixx.io/blob/master/examples_attiny/serialcontroller/serialcontroller.c

Regards

David

​Interesting approach. What do the power consumption numbers look like for a mote running something like this?

The primary problem I see with this type solution is that you’re still not able to update the underlying OS and application software. This means that when (not if) a security or safety flaw is discovered there’s no easy way to deploy an update. Updating a WSN with hundreds or thousands of tiny sensors powered would be beyond a headache. Depending on the deployment updating each device by hand using a JTAG or similar connection may not only be expensive but technically infeasible.

I understand that a generalized framework for such tiny and specialized devices presents a certain challenge but many people would have balked at the idea of an OS that supports such a diverse range of microcontrollers. While I’m in no way an expert in the field I would hazard to guess that a non-volatile file system would be required (or at least it would make things much easier) as well as a ultra lightweight bootloader. An image could be transfered to the mote, stored in the file system, unpacked if required, moved in to place, a config parameter would be set to the location of the new image, the the mote would reboot, if all went well you’re up and running. In the event of a failure the previous image is marked as active, the device reboots, and you’re back to where you started.

–adam

Hi,

I understand that a generalized framework for such tiny and specialized devices presents a certain challenge but many people would have balked at the idea of an OS that supports such a diverse range of microcontrollers. While I'm in no way an expert in the field I would hazard to guess that a non-volatile file system would be required (or at least it would make things much easier) as well as a ultra lightweight bootloader. An image could be transfered to the mote, stored in the file system, unpacked if required, moved in to place, a config parameter would be set to the location of the new image, the the mote would reboot, if all went well you're up and running. In the event of a failure the previous image is marked as active, the device reboots, and you're back to where you started.

On embedded linux systems, many vendors deploy a ping-pong kind of approach. Flash is devided in half, and the bootloader as a variable saying which half it is supposed to boot, and many have a boot counter that says "if booting fails three times in a row, switch to the other image".

I could imagine that something like this could be deployed in a generalized way on MCUs. Like, as soon as we can write to flash from within riot, we could hook in at the earliest stage possible, and then from that point decide which area of the flash to use for continue booting. Then we could seperate the very eraly initialization stuff

That still would require per-device support in e.g., linker script and very early system setup, but image downloading, flashing, verification and so on could be generalized. Downside is that an image can only use half of the flash (minus static initialization stuff).

We should definately look into something like that.

Kaspar

There was also recently this PR https://github.com/RIOT-OS/RIOT/pull/1421

Just yesterday we saw a demo of this with OTA (minimalistic) application software update.

Best

Emmanuel

It’s great to hear that not only are people keeping this feature in mind but that there’s been some work done on it. OTA upgrades aren’t something I need right now but I don’t imagine it’ll be too long until I get to the point where it’s going to start to become more important.

@Kaspar, that sounds great; I’m glad I wasn’t totally off base with my concept of the update mechanism. I’m pretty sure that’s how most modern BIOS upgrades work these days. I remember the “good ol’ days” when one false move while updating a BIOS would kill the motherboard. I sure don’t miss prying corrupt EEPROMs from boards to reprogram them on the bench manually. You do have a point about only being able to use half the flash. Unfortunately, I think any method used to avoid that penalty would increase the complexity enormously and probably make the whole update process more fragile.

What about a multistage update? If a stripped down minimal image was used in an intermediate step you may be able to reduce the amount of flash required to perform an OTA update.

  1. Free as much flash as possible
  2. Fetch a stripped down, minimal image (hardware and file system drivers, hash libs to verify an image, maybe some basic diagnostic tools, etc…)
  3. Write the image to a designated area of the flash
  4. Verify the image
  5. Set the bootloader variable
  6. Reboot
  7. Fetch the full upgrade image
  8. Overwrite original image
  9. Verify
  10. Reboot

(If the device fails to boot properly a specified number of times the loader sets the variable back to the primary image and reboots.)

Actually, depending on how small the image could be made and how much spare flash the device has, the minimal image used during OTA updates could be shipped with the device. The minimal image could be used in the event something corrupts the primary OS image or any other emergency scenario arrises. The minimal image would have to be device specific but no more than any other image and seeing as it’s simply a cut down version of the production image it would be easy to build.

With a few more steps and a couple more reboots even the minimal/upgrader/emergency image could be updated in a similar way without sacrificing too much risk of bricking a remotely deployed device. Bandwidth and power could potentially be saved if the upgrade images were deltas instead of full images.

Anyways, I’m very encouraged that people are keeping the possibility of OTA updates in mind. It’s a feature that I’d really love to see in the future?

Hello Adam,

my group is also currently in the process of defining the requirements for an over-the-air update facility in RIOT. However on our specific board, we couldn’t dare to spare half of the on-chip flash memory for the backup image. On the other hand, we have a rather large external Flash memory (~32MBit) on the board, which would be a waste not to use.

So in our approach, we will need some generalization on where the new and the backup firmware is stored. In my opinion this part must be board-specific. It is anyway a CPU-specific task to program the on-chip memory at runtime, and even that is not possible for some CPUs at all, and for some only when the respective memory parts are not write-locked.

My group has unfortunately not yet started with our port to RIOT, so we don’t have any expertise there yet. However as soon as we’ll get our hands to it, we will start developing towards OTA. And hopefully we can get parts of the RIOT community to join in. As a startup company, we may have access to funds supporting such intentions.

So i’m also glad to hear that OTA isn’t only something that would be nice but is too hard to imagine, but rather something that looks like it’s actually wanted.

Oh, and just to introduce myself to this list: I am a student from Berlin, currently working on my diploma thesis and involved in a startup that develops an intelligent lighting system.

Best regards Janos

Hey Kaspar!

I could imagine that something like this could be deployed in a generalized way on MCUs. Like, as soon as we can write to flash from within riot, we could hook in at the earliest stage possible, and then from that point decide which area of the flash to use for continue booting. Then we could seperate the very eraly initialization stuff

Have you ever wondered what's https://github.com/RIOT-OS/RIOT/blob/master/drivers/include/flashrom.h for? :wink:

Okay, it's only implemented for MSP430 and ARM7 afaik, but it's usually not difficult to implement this stuff.

Cheers, Oleg

I’m not sure how I missed that. You’re taking all the fun out of my needlessly complicating things.