Differential FW update

Hello,
in my new GPRS application I have necessity to reduce at the minimum the quantity of bytes transferred for a "firmware update over the air".
For what I have understood this technique seems based on a differential concept; the hex file is not an image of the program memory, but contains only the sections which are different from previous fw version, and the informations about where these various patches must be applied.

So, is it possible instruct the compiler to assign absolute addresses to new procedures, leaving the previous version almost unchanged ?

Regards,
Marco

Hi Merlin,
sorry for late reply, but I was in holidays last days...

I agree it's not easy to manage the various Fw versions, but I cannot believe there is not a way to optimize at compile time the hex file...
For example if I have a mega256 with 140 KB used by firmware; if now I add a simple procedure() I must reflash almost all pages !!?

About the example above, a simple raw option I can imagine is to put the new procedure on top of previuous image file,
changing only the pages where it is called.
I understand it's "simple to say", but the result is that you have to send only few hundred of bytes instead of say 141Kb !

Of course this is a problem only when you pay for the bytes transferred (via GPRS), but when you have thousands of devices to upgrade
this can become a big problem...
Also when your competitors in a possible project claim to have such kind of feature to offer...

RFC,
Marco

Hi Avra.

The main problem that I see with this is the way that the assembler is organised. User code, which is the most likely to change (and least likely to be the same size) is organised at the front of the code. Everything else is shuffled down. That means that the 'difference' is likely to be most of the code.

I agree 'bootloader' is the answer, but I think that either you need some way to make the functions likely to change a fixed size (by, for example padding with NOP statements), which in larger processors should not, in principle at least, be a problem, or something smarter than a simple difference engine, i.e. one that than can calculate how to move existing blocks. The latter though also requires a pretty smart bootloader. You may need, at different times of day, to transmit different upgrade paths to handle jumps in versions as I mentioned before.

The problem, as I see it is not just to make a difference engine, but to make the differences themselves as small as possible.

Hi Marco.

Situation (a) is more difficult than it seems, ignoring for the moment that it does not at comply with AVRCo. Something (maybe many things) will need to call it and these areas will also need to be updated.

Situation (b) is quite simple and OK.

Situation (c) suffers the same difficulties as situation (a) so padding (to effectively change situation (c) into situation (b) might be a better option.

Now, as I say, adding procedures at a specific page does not comply with how AVRCo works, so how could one get around that with AVRCo? Well, if you know in advance that the procedure will exist (for example with situation c) you could use indirection, which AVRCo supports, to point to the functions and then update the pointers. If all pointers are kept in the same area, then effectively moving the functions to a new page would be quite easy (well, relatively speaking!) However, you would have to be sure that you always call a function via its pointer and not directly! The first version could be a true AVRCo program and subsequent ones could be updates.

Sensibly the boot loader should be aware of these pointers, otherwise v1.1 applied directly will have a different image to v1.1 applied over the air, so an upgrade to v1.2 might fail for one or the other. However this might make the boot loader too big for the boot loader space. I don't have enough experience with boot loaders or XMEGAs to know if that is an issue or not, but I am thinking that with care this can be circumvented and that the 'intelligent' part of the boot loader can exist outside boot space, calling functions within the bootloader space to actually update the flash.