In-field update

Hi to all,
I try to update my in-field system but I have a question.
My application consists in more than one dll, if I would to update my system, how can I build a hex file that contains all my assembly?

If I use “SystemUpdate.ApplicationUpdate.Write”, the system understand itself with assembly will be to write?

I used a PandaII and Hydra.

Thanks to all.

If you are trying to update certain assemblies, you may want to consider a Dynamic Assembly Loading… take a look here:


Thanks Jay Jay,
Perhaps I expressed myself badly.
I don’t need to know how to load a plugin or assembly, what I would like to know is if to upgrading my application with “SystemUpdate.ApplicationUpdate.Write” I need a single file with all my assembly (like .hex?) or with “SystemUpdate.ApplicationUpdate.Write” I can to update all of my application file.

for examples.
App1.exe -> Main application
Dll1.dll -> Support assembly
Dll2.dll -> Support assembly.

If I deploy with Visual studio, it deploy all anche upgrade all.
If I would to upgrade automatically via code, how can I do?

Thanks to all, I hope I explained myself properly.

Hi John,
Please take a look at Pyxis2 it contains what you need…
it has an installer/updater and how to do the infield update code…


Thanks Jay Jay for link, but I know that the way to write an updater/installer.
I need to know how to create a .hex file. In pyxis’s documents I can’t find any information to create that file.


Hi John, Please read the following:

Obtaining the Application File
To obtain the application file, first you have to develop your application and deploy it to the device using Visual Studio. Next, you can read it using MFDeploy (on EMX and ChipworkX) or GHI loader (on USBizi). The needed file is a SREC file with the application assemblies.
For MFDeploy, first make sure Application mode is active because MFDeploy will be reading this region. Once active, go to “Target->Application Deploymnet->Create Application Deployment”. Then select the application file name and a key to sign your application. Note that you only need your application hex file and NOT the key or the signature file (.sig) for in-field update. MFDeploy documentation has all necessary details.
For USBizi, MFDeploy cannot read your application. It has to be read using GHI’s bootloader, see ‘G’ command in USBizi user manual. This command will read the entire FLASH (managed bootloader and main application) as binary format which is not what exactly needed. To extract the application in SREC format, we need to convert the first 96KB. This program does this for you. You have to invoke it using the command line and provide an input file name. It will then output the needed application file. The source code file is here for reference.

You can find the whole document here:

Thanks Patrick, I already read it, but when the Hydra execute this command SystemUpdate.AccessApplication() (or SystemUpdate.GetMode()) it throw a NotSupportedException.

The previous command is real unsupported or I wrong somethings?


Isn’t In-field update a premium feature? The new release of .NET MF has a built in functionality for updating the firmware, but i didn’t browse or see any examples yet. This is what should be used on boards like Hydra.

Thanks Gralin, I know it now. Hydra not support a premium library.
In next versions (4.2?), does it support premium library?


It is up to the community to what feature will be added to open source (OSHW) products like Hydra.

If you need one of the premium features (wifi, IFU, SQLite, PPP, USB Host…) then you need spider fro example

This should help

and this

ok, now I understand
thanks gus.

Each board you program with C# (either it’s Hydra, Netduino or other) has .NET MF inside. Each version brings you new features. The new one (4.2) brings (among other features) in-filed update.

Now what GHI offers is a set of premium libraries for some of it’s products that offer functionality that is not available on other .NET MF boards. Today you can see that a feature that was available in the past only for GHI customers will now be present on all .NET MF boards. You still can however use GHI implementation (unless it’s marked as deprecated in the future).

Will have to see about that! When NETMF brought WiFi 2 years back, all it did was expose a method to load SSID and other parameters, not exactly WiFi support! I never looked in IFU in 4.2 and not sure how well ti will work. Never seen any product with IFU from 4.2 either.

The good news is that 4.2 hydra is done and SDK/sources should be online tomorrow. So who will volunteer to test out the IFU feature found in 4.2?

@ Gus I didn’t see or hear anyone using the built-in in-field update from 4.2 either. I just remember seeing it in the release notes. Maybe there is some info in the netduino forums as their community is experimenting with 4.2 for a longer time i think.

I doubt IFU will run on any small device, or I will be really surprised if it did. You need a lot resources to update a device, unless it is really limited. But I look forward to seeing a real implementation on 4.2 IFU as it will help everyone interested.

Hi Gus and Gralin,
thanks for answers.
Sorry for my ignorance, but IFU what is? Is like field update?
If yes, we are very interesting to test IFU on Hydra.


See this: