Remotely upgrading only one section/functionality of an entire software

Do you really mean "upgrading" (adding functionality different from how the board was shipped from the factory) or "enabling" (purchasing a license for a feature)?

How big an OS are you using?

This is something that a 'big' OS like Linux, VxWorks (icky), and Windows (ickier) all support. Either through a loadable library (Windows uses the DLL, I can't remember the names that Linux and VxWorks use), or with separate applications communicating with one another.

You define your interface, you partition the functionality _before_ you write all the code, you put the mutable stuff into loadable libraries, then to do your upgrade you just upgrade the library. I _do not know_ if you can get away with doing this method without rebooting your application -- you'll have to research.

Alternately, all of these OS's will let you have separate applications running as separate processes, communicating with sockets or whatever. Swapping out an application becomes more structured, although you still have issues with how to get 'er done if you want to do it on the fly.

Heh -- that one is _easy_.

But, you will have to make sure the "module"/portion that is being upgraded is not accessed during the upgrade process. Can you do this? Does your *other* code reside in the same physical device? (i.e., can you be upgrading one portion while executing code out of it at the same time?)

How is your application sturctured? At the very least, you need some way of compartmentalizing the portions that you want to upgrade. You can choose whatever size/shape "compartments" you want. As long as you can govern access to those individual "compartments" during the upgrade.

For example, you might decide you want to treat the FLASH as a set of 1K compartments -- any of which can be upgraded independant of the others. Or, you can treat it as a set of one *byte* compartments. As long as you can keep the processor from trying to *use* the compartments that you are altering *while* their state is indeterminate.

(e.g., if you can keep the processor out of the entire flash, then you can pick and chose which individual *bytes* you modify)

As far as not having to reboot, that is possible if you don't have any "state" that has been corrupted/invalidated as a consequence of the upgrade (or, if any such problems are fixable as part of your upgrade/recovery procedure)

Upgrading system components without reboot requires guaranteed correct handling of all dependencies and states. This is non-trivial problem which very well can be insoluble unless your system is specifically designed for that. The upgradeability on the fly will cost you a lot of software overhead and complexity, so the best way is drop this idea.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Linux :-) with minimal functionalities along with filesystem.

if

The trick of having the section of software that is to be upgraded as a library and upgrading only the libraries is interesting :-) . Yes, that avoids the upgradation of the complete software. I think the partitioning of the application w.r.t memory can be done using the Linker Script and while partitioning we need to have a separate memory section/segment for library . In this way, i think that section alone can be overwritten with the new library. But, Is the above method feasible in linux ?

=A0

Can you pleasse elaborate this method ?

Thx in advans, Karthik Balaguru

Google is your friend: