Creating config.hex file for Fez Config on G120

1

Hi,

I am using a G120 for a product that uses IFU to update the application. We have some config parameters that we want to load to the part when we make it (HW version etc), and then persist when we update the application (only) via IFU.

I can create the config values programmatically using Configuration.WriteEntry, and all works well as I update the app and the values persist.
I would like to flash the blank parts using Fez Config, and write the application hex as well as my own version of config.hex (as when using the “Firmware Updater” tab). I can only update the app using Deployment.

However, I can not find how to make my version of the blank config.hex file that comes with the SDK. I have tested just flashing that, and it blanks the config, leaving the app alone. So, I only need to extract my custom config.

Is there a way to make a config hex file of a config stored in the G120, so that I can set up parameters, make a config.hex and then flash them to multiple parts using Fez Config (rather than deploying a program to write them, and then flashing the app over that).

Thanks in advance.

Nick

1 Like
2

Unfortunately there is no out of the box way to read the entire config region as a hex file using MFDeploy or FEZ Config.

By looking at the NETMF source you may be able to transform the data read from Configuration.Read() into a hex file for your device. We have not done that ourselves before though.

You may also be able to use the assembly backing MFDeploy to read the config region yourself in a quick desktop test program you write. See C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeployEngine.dll.

As an alternative, you may be able to include the configuration data in your program and write it to the device. You can check a config entry on startup for current version flashed and if the data you have in the program is newer, overwrite it.

Roughly something like the below. Keep in mind it hasn’t been tested. Whenever you go to do a new app deployment for IFU, just update the data in config and version.

class Program {
    private static byte[] config = new byte[] { 0x00, 0x00, ..., 0x00 };
    private static byte version = 5;

    public static void EnsureConfig() {
        var version = Configuration.ReadEntry("AppVersion");

        if (version == null || version.Length != 1 || version[0] < Program.version) {
            Configuration.Write(Program.config);
            Configuration.WriteEntry("AppVersion", new byte[] { Program.version });
        }     
    }
}
3

@John_Brochue You mention some possible methods of reading the Configuration Sector. Do you also think it may be possible to flash the Configuration Sector if I write a script based on the pertinent parts of MFDeployEngine.dll?

I ask because it sounds like a task that may be quite hard for me, but if I could flash the Configuration Sector from a PC then it is likely worth the endeavor.

4

The classes in MFDeployEngine and the underlying debugger assembly are the same used by Visual Studio to communicate with the device, so you may be able to read and write the entire configuration region. We haven’t done this exact scenario before so I can’t say for sure.

An easy first step would be to take a look at the source of MFDeploy to get familiar with the underlying debugger API.

5

Thanks for the pointers…

MFDeploy already seems happy to flash the config.hex (as provided for default in NetMF), so it is only the reading that is missing. I haven’t tried but the documentation shows MFdeploy flashing config.hex from command line.

I grabbed the source of MFDeploy, but it doesn’t compile in my current VS setup, so I need to check and update some references somewhere. But, MFDeploy can grab an application and also flash a config (from the default one provided).

So, I figure I can find the memory range that it uses to flash the config and then modify the read app code to read that instead, and save to a hex file. A few tests to see if different config contents change the addresses etc, but might get me going.
Shame that MFDeploy does so much else - just got to dig through it to find the right bits.

One for the to-do list, I suspect… I am currently deploying a quick app to write the HW version in to configuration for each board , and then flashing with the actual application. Then the HW version just stays there through all IFUs.

Cheers!

Nick