Partial-Firmware Mesh DFUs

[Thomas-Brilliant]

I recently added Mesh DFU support to a project that I'm working on but it's extremely slow. It will take at least 1 hour to update the network under ideal conditions but I'm aiming for an update that will complete in less than 10 minutes.

I can think of only 2 feasible ways for me to achieve my goal of a sub-10 minute update.

The first is to increase the rate at which the DFU packets are sent. Right now, I send a DFU packet ever 2 seconds. I've tried faster rates but that usually leads to lots of lost packets.

The second method to achieve my goal is to decrease the firmware size. I've applied some optimizations and stripped out unnecessary code, but my firmware is still pretty large (90+ kB). I did notice that most of the the firmware consists of SDK-included libraries that I never touch. All of the code that I wrote (and will likely ever modify) is less than 10 kB.

So here's my question. What would it take to only push portions of the firmware via Mesh DFU?

[Edvin]

Hello,

The reason why the Mesh DFU is set to go so slow is because Mesh networks has very low payload throughput. As you say, it is possible to speed it up by sending the packets more often, but this may result in more packet loss, both for the DFU packets and the mesh networks application packets.

The advantage of the Mesh DFU is that the DFU is running in the background, meaning the (old) application will still run while it is receiving the new one. It only requires a restart once the entire packet has been transferred. 

May I ask why you need the DFU to update faster?

If you need to update faster, I can really only recommend using the bootloader from the "normal" SDK, which takes less than a minute, but then you have to be in range of the node, and in a BLE connection. You also need to update one node at the time, which is typically not ideal for a mesh network wich possibly have very many nodes.

Best regards,

Edvin

[Thomas-Brilliant]

Hi Edvin,

I'm looking for a faster update so that I can rapidly develop firmware updates for my test device (which is sealed up, so I can't connect my J-Link to it).

Is it possible to combine the "normal" SDK bootloader's functionality with the mesh SDK bootloader? If so, how would you suggest I go about it? Do you have examples?

Have you ever tried splitting the application into different sections so that each section can be updated independently?

Thanks,

-Thomas

[Turbo J]

Thomas-Brilliant said:

Have you ever tried splitting the application into different sections so that each section can be updated independently?

That would be stupidly difficult to set up reliably. Forget this idea, the compiler likes to reorder stuff around anyway.

Thomas-Brilliant said:

Is it possible to combine the "normal" SDK bootloader's functionality with the mesh SDK bootloader?

Maybe, but the result would probably significantly bigger in flash. How much of that is still free...?

Also very much non trivial.

Thomas-Brilliant said:

test device (which is sealed up, so I can't connect my J-Link to it).

That can be changed with a sharp knife and a soldering iron...

[Thomas-Brilliant]

Turbo J said:

That can be changed with a sharp knife and a soldering iron...

Hahaha true but this solution won't scale well with my team nor will it be viable once our product is installed in the test fixture.

[Mark Q]

Technically speaking, what you are referring to is a binary diff.  So, instead of sending the whole object code, you send just the parts that have changed.  This is possible but would require quite a bit of work to implement from scratch.  Please take a look here and here.