Infield updating

I plan on creating an update process for my fez raptors and have been looking at the document:

https://www.ghielectronics.com/docs/147/in-field-update

This contains a line of code:



Where do you get this file from???

It is imperative that the SSL seed and its assigned MAC is not wiped from the device when it is updated (which is why I am guessing you need the file mentioned above), is there some code to copy out the configuration part of the flash and reinsert it once the update is completed?

@ networkfusion - The LoadFile function is defined in the Getting Started code example on the document you linked. When loading the configuration, the SSL seed and MAC address will be reset. You can read the MAC address, save it to an SD card or some other form of external storage, then reload it on the next reboot. For SSL seed, I am not aware of any method to set or read it from code so you cannot save it.

@ John - Thanks for your reply.

I understand the LoadFile function, but not where the “Config.Hex” file comes from? (MFDeploy only generates the [firmware].hex)

Is the SSL seed not saved within the “Config.Hex” file?

If the SSL seed cannot be set from code and if it cannot be set from a config.hex file, I am guessing that infield updating is out of the question as we will rely on the ability to connect to an SSL connection (azure service bus) ???

Can the part of the flash containing the config be copied to an SD card and then reflashed after the update process is complete?

i asked for the same thing long time ago… extracting config.hex should be possible but there’s no tools for that

@ networkfusion - I’m sorry, didn’t see the file part. You can find the config.hex and firmware.hex files in our SDK, C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Firmwares\G400 for example. I believe the SSL seed is saved in the config.

Persisting the configuration settings between IFU calls (and potentially even firmware update) is something we are looking into but have nothing at this time.

@ John, any update on the ability to persist ssl seeds and mac address between firmware updates?

@ networkfusion - when using in field update you mean? Or fez config?

When infield updating…

If you have and SD card or an extra Flash chip connected, you could store all the information there.
On startup you compare it, and if different write it back to the device flash and reboot once more.
This is how I do it with the Mac address, and it works really fine:

var myMac = GenerateUniqueMacAddr(uniqueId);
if (!ByteArrayEquals(eth.PhysicalAddress, myMac))
{
   //update the Mac Address
   eth.PhysicalAddress = myMac;
   //Hard Reboot the device so the newly Updated MAC is taking into consideration.
   PowerState.RebootDevice(false);
}

instead of generating an MAC by the serial number I have stored on SD, you could read your MAC from SD or external flash.

That is an idea :smiley:

Shame it is not possible with the SSL seed which is the most important thing for me!

@ networkfusion - While we did not change IFU to persist the SSL seed or other configuration, the latest pre-release SDK has methods to read and write the configuration. Combined with an SD card or other external storage, you could persist the SSL seed.

@ john, which namespace would I find these functions in?

@ networkfusion - GHI.Processor.Configuration.

@ john thanks.

Since the configuration is loaded into RAM before it is written back to flash, is there any need to persist it to an SD card beforehand or could I just do something like:


using GHI.Processor;
InFieldUpdate.Load(InFieldUpdate.Types.Configuration, Configuration.Read(), Configuration.Size);

@ networkfusion - You can’t use the data returned from Configuration in the InFieldUpdate class. You have to persist it somewhere externally since the board resets after IFU flashes the new data.

OK,

I will make sure I persist it to external storage first :think:

@ networkfusion - You could also not flash the new config file in IFU. Everything should work fine if you flash just the firmware.

Thanks, I will do some experimenting.

The only worry I have is if the configuration structure is changed in V.Next but I guess that will be a bridge to cross as and when it is needed…