LWMesh OTA Upgrade

[fgargiulo]

I was looking for some information on OTA over LWMesh. I found some documentation on generic bootloader and OTA but for Zigbit and RF4CE. I was wondering if there is something already implemented over LWMesh, as i could not find it on Atmel website. Should i use a generic OTA Cliente and OTA server? If anyone has any information about it I would really appreciate it.

[ataradov]

Should i use a generic OTA Cliente and OTA server?

What generic servers and clients do you mean here?

LwMesh used to include OTA upgrade functionality, but it was only supported on ATmegaRF256RFR2, and it was not really great. It was removed at some point, in hopes that it will be replaced by a better thing, but that never happened.

I can give you a version of LwMesh that still has it, if it helps any. But in general, I'd roll your own, depending on the application. I can give you some pointers, if you describe your application in more details.

[fgargiulo]

By generic i mean my own implementation, with some known application as base ground (perhaps some example code of a ZigBee application). If you have any documentation though it would be very nice to have it, with special emphasize in the bootloader implementation and if it uses internal or external flash to store the image.

In my application all nodes report to one coordinator, so i was thinking of some implementation where once a node has completed the over the air upgrade, it can take the role of an OTA server (in order to improve the whole process, as it would take less time and prevent bottlenecks).

[ataradov]

By generic i mean my own implementation, with some known application as base ground (perhaps some example code of a ZigBee application). If you have any documentation though it would be very nice to have it, with special emphasize in the bootloader implementation and if it uses internal or external flash to store the image.

The general idea of the ZigBee OTAU protocol is not bad, so you may want to implement something similar.

General idea is this:
1. All devices send new image requests to the gateway once an hour or so.
2. Gateway can ask device (or all devices) to request new image.
3. If device asked, and gateway responded that the new image is available, device starts requesting chunks of that image. It is important that device sends requests and gateway sends responses. This way gateway does not need to keep track of all current downloads. This makes gateway salable. Depending on the load, gateway may ask devices to slow down their requests.
4. Once download is complete and image is verified, device notifies the gateway and gateway tells it to wait, or update immediately. It is important to be able to wait, in case you are switching to an incompatible protocol.

Whether you use external of internal flash depends on your device architecture and memory already used by the application. If you can fit two images in the internal flash, then this would be the simpler approach.

In my application all nodes report to one coordinator, so i was thinking of some implementation where once a node has completed the over the air upgrade, it can take the role of an OTA server (in order to improve the whole process, as it would take less time and prevent bottlenecks).

If you have less than 100 nodes, then I would stick with the central gateway providing the updates.

[fgargiulo]

Our goal is a network of 1000 nodes, so i guess it's going to be necessary for updated nodes to also provide updates. I'be been working with your simulation software and made a few tools for setting up network configuration and for analyzing results (how routes were conformed, how many packets were successfully received over the total that were sent, etc). I'll send them to you once finished.

I've done some minor changes to the stack in order to make it work with 1000 nodes. I've still noticed some strange behaviors that need to be taken care of, but so far it's been working pretty great. As you once told me, the key to make it function properly was to limit the number of routing nodes.

Back to the OTA issue, i think i'm gonna start with the ZigBee OTAU as an example and see if i can find more documentation specific of LWMesh.

[ataradov]

Our goal is a network of 1000 nodes

In that case I would slightly amend the algorithm above. Instead of asking the gateway, nodes should send link-local requests of the same nature. And pick one responding node and use that to poll for image chunks.

This will cut down on routing traffic, since there won't be any. And this will basically propagate the image from the gateway towards the end of the network.