This question is more like a consulting ad than an actual question. 
To be able to help you will have to have some knowledge of compilers
and patching techniques.

Here is our problem:

We create embedded devices that communicate with our servers over
cellular networks.  We have the ability to remotely reprogram these
devices with new code at any time.  Currently when remotely
reprogramming we send the entire Flash image to the device which
stores it in SRAM and then ReFlashes itself with new code.  The
process is reliable and works very well.

The issue is that we would like to decrease the size of the remote
reprogramming data package hopefully by using some type of patching or
by sectioning code into blocks that represent different
functionalities of the device.

Though we could do it ourselves I beleive that someone with some
experience could help us accomplish this very quickly.

THank you,

Mandeep

PS.  I have put a small price here just for getting me a "lead" and
from there would handle the actual cost of the project.

---

Request for Question Clarification by maniac-ga on 03 Mar 2005 19:00 PST

Hello Mandeep,

What Neutron_coding suggests is certainly feasible though if I was
doing this, I would likely make the granularity a bit larger (groups
of functions / separate relatively "static" functions and those
subject to update) and apply a few other methods. Can you describe:
 - the tool chain you are currently using (e.g., compiler, linker, ...)
 - the target environment (e.g., processor family, total memory,
amount spare memory)
 - typical function size in terms of target memory size
so I can help you a more specific answer (than general techniques).

  --Maniac
u

---

Clarification of Question by mdeeps-ga on 03 Mar 2005 19:18 PST

The Microprocessor in use is an AVR Mega128.  
Flash size is 128k.
Available memory for this use is 96k.

I will get more clarification from my team but I believe
avr-gcc set of tools is being used

The number of functions is huge here, we have quite a complex little
embedded application with multiple threads all running on top of the
open source Ethernut RTOS.  It is more reasonable to split code into
blocks by thread or library than function.  Even so I beleive the
ideal solution would be a real Patching solution that will detect the
areas that have changed and instruct the microprocessor to move things
around as needed.

The other reason we would like to make this happen is because we have
a virtual code size limit of 96k even though there is 128k of Flash
because there is only 96k RAM available to store the new Flash file.

My work with embedded devices is limited to just hobby type
programming with Zilog microproccessor, so what I'm about to suggest
might not be the best or easiest way to go and should be taken with a
grain of salt. (I'm assuming you're using some sort of microprocessor)

What you're asking for should be pretty easy to implement. The idea is
seperate your code into functions. Once you have seperated your code
into individual and separate functions, you would place those
functions into known blocks in memory, with empty space between
functions for future growth. For example:

0000-0090
[Flash Loader]
0100-0190
[Function 1]
.....

Now when you want to upgrade your programming, you would only upgrade
certain functions. Then you could just flash certain blocks in memory
and not the whole operating program. In the above example, if you
wanted to upgrade Function 1, memory addresses 0100-0190 would be
written over with the upgraded function.

This would allow you to send less data for upgrading the FLASH.
However, if there is a major change to the operating program, or if
the upgraded function is to take more memory space than previously
allocated, a full FLASH upgrade would be necessary.

One of the problems you are faced with in this topic is the client
will need some type of program that actually performs the 'patch'. 
Usually this is just a hex editor that can locate the spot you want to
change, insert the new hex (assembler) code, and be done with it.  You
don't have to worry about re-compiling, etc.  Currently it sounds like
you compile, then replace the version that is on the device.

The functions I'm referring to might be thought of as objects in C++.
Big enough to be a sepate object, small enough so that updating is
easy. Your OS and objects that do not need to be upgraded would not
have to be separated. You would take the threads that you update
frequently and put them in separate and know locations in memory.

Or as you have suggested in the clarification question, treat each
byte in memory as function. Run a difference program between the
updated and original program memory blocks and just update individual
bytes in memory. This would be the ideal solution. However, this would
only be ideal with small updates, as you would have to transmit memory
locations for each byte or blocks of bytes being updated.

Depending on how big your OS is, and if you have to transmit your OS
with each update, you can start by putting your code in a known space
in memory. You would then only update your code, unless there is an OS
update, but those would be rare. You would in turn save transmitting
your OS.

The difference program would be easy to implement, writing the new
flash programmer would probably be a little harder. What updater or
method of update are you using? If it supports updating individual
FLASH cells, which I'm sure it does, or one that does can be found, 
you would only have to write a difference program.

What your asking for is probably too specialized for a question on
google and might take longer to come up with an answer. You might want
to try Monster.com or any other job search site for someone to take on
your work on a project basis.

Going through some background on AVR microprocessors, I discovered
what seems to be the main obstacle in you problem. You need a boot
loader that can write individual bytes or blocks in memory. Currently,
you are either using the Atmel boot loader which I believe requires a
RS-232 link. Or more likely, Ethernut Ethernet Boot Loader(EEBL),
which allows Flash upgrades over a network. If you are in fact using
EEBL, it's just a matter of modifying the source code in order to
implement block Flash access. If you wouldn't want to take on such a
task, maybe you can contact the Ethernut team and ask them to
implement it for you, for a fee or donation to their project. You can
also post on their forum, and ask if anybody would be interested in
such a project.