G120 In-field update

NETMF & Gadgeteer
1

Hi,

We have some units with EMX modules transitioning to G120. We use the in-field SystemUpdate capability in the EMX quite successfully but it appears things have changed in frameworks used by the G120.

This link shows the new function calls: https://www.ghielectronics.com/docs/147/in-field-update

I have a fundamental type question… old system used to boot into a bootloader, and there we had code that could update the App or whole platform.

I don’t see the concept of booting into a bootloader (SystemUpdate.EnableBootloader();), as now SystemUpdateType only includes an Application area (along with Firmware/Config).

Does this mean the update method is much simpler, but has more potential for failure? As the bootloader no longer exists I assume that if the app update fails, the only resolution is flashing using Tinyloader now.

Just checking I’m not missing something,

Thanks!

2

Actually less room for failure as the system does everything in RAM. FLASH writing only happens when all is 100% complete.

3

Well that’s great to hear. I like the simpler approach of a single image to write/manage. The whole dual boot/images was kind of messy but worked solidly for us.

If I have a 4.0 EMX with dual code partitions and try and run an update using the old SystemUpdate to the new 4.2 SDK Firmware/Config and App files, how would the EMX updater cope?

4

Since the new system is different and does not split flash, it is not possible to use infield update to go from 4.0 to 4.2. You will need a manual update this one time unfortunately. We understand this may not be a favorable option but it will result in a much better IFU feature now and in the future.

5

That sucks.

I guess we now have to run 2 builds/code paths to support older units. Not the end of the world, but thanks for the reply so I don’t waste my time trying.

6

you may still try to do a “complete update” from the old system if your software supported it. It will probably work!

7

When you say a “Complete update”, you mean passing all files?

What would we use as the bootloader?


            string[] files = new string[]{
                "CLR.HEX",          // GHI firmware
                "CLR2.HEX",         // GHI firmware
                "Config.HEX",       // GHI firmware
                "app.hex",          // main application 
                "bootloader.hex"    // managed bootloader (this)
            };

            // start update
            SystemUpdate.CompleteUpdate.Start();

            foreach (string fileName in files)
            {
                FileStream file = new FileStream(folder + @ "\" + fileName, FileMode.Open, FileAccess.Read);

                // read the file in chucks
                byte[] buffer = new byte[10 * 1024];
                int length;

                do
                {
                    length = file.Read(buffer, 0, buffer.Length);
                    SystemUpdate.CompleteUpdate.Write(buffer, 0, length);

                } while (length == buffer.Length);

                file.Close();
            }

            // End update
            SystemUpdate.CompleteUpdate.End();
8

If I remember correctly, there was 2 ways in the old IFU (it has ben few years so I am not sure). One way, that will format the flash into two regions. The other way, will not do that and instead you can update everything in the system, including tinybooter.

It maybe worth the try or looking into if this is very important to you.

9

Yes, well we support both methods in our bootloader. App only or CompleteUpdate (as shown). But CompleteUpdate required the bootloader image too.

Capturing a new 4.2 bootloader image might be interesting as the image base address must be different and that mode no longer exists.

Perhaps a CompleteUpdate to a modified bootloader which can then disable the dual boot mode while flashing a second new firmware would work.

Well maybe it is worth a little look after getting G120 working.

Thanks