Update mechanism pyxis2

I need to update my Spider project once in a while and I was looking at the IFU mechanism. I found the Pyxis2Updater and I was wondering if the pyxis2updater is usable on Spider or should code be changed to use it with spider / gadgeteer?

@ Skewworks will be along sometime to comment, but Pyxis2 is certainly the reference for how to do IFU. There should be no significant changes needed for Spider, but you will have to make sure things work in accordance with the SDK version you’re using now.

Pyxis 2’s updater uses GHI’s IFU so, yes you can port it to any of their devices that support IFU :slight_smile:

If you have any specific questions just post here and I’ll watch the thread.

ok, I’ll start porting it to Spider Gadgeteer and post updates or questions here :slight_smile:

I’m interested in this too - will likely need to use this for my rovers. Not sure exactly which board(s) I’ll end up with on the beta bots.

I’ve changed the code to support the spider. In my application I added the code to split the flash to support the two partitions:

 switch (SystemUpdate.GetMode())
                case SystemUpdate.SystemUpdateMode.NonFormatted:
                case SystemUpdate.SystemUpdateMode.Bootloader:
                    throw new Exception("Invalid Boot Mode!");
                case SystemUpdate.SystemUpdateMode.Application:

On first run it creates the two partitions and redeploy my application. When i force my application to go to deployment bootloader mode:

            if (File.Exists(NormalizeDirectory(storageDevice.Volume.RootDirectory) + "bootloaderdemand.txt"))

I can’t deploy my update code, pc can’t connect to spider. Only solution to get back to a working spider is to use the ghi firmware update program.

What am i doing wrong?

Ok, I’m one step further.

Accoording to the documentation EMX (spider is emx based) has an bootloader flash partition of 192k. The smallest app based on gadgeteer is approx 209kb. I copy/ pasted the code from the ghi documentation:

using System;
using System.IO;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

using GHIElectronics.NETMF.System;
using GHIElectronics.NETMF.IO;

namespace Example
    public class Program
        public static void Main()
            if (SystemUpdate.GetMode() != SystemUpdate.SystemUpdateMode.Bootloader)
                throw new InvalidOperationException("We must be in bootloader mode!");

            // set up the right button to do the system update
            InterruptPort rightButton = new InterruptPort(HardwareProvider.HwProvider.GetButtonPins(Button.VK_RIGHT), true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);

            // wait for it to be pressed
            while (rightButton.Read())

            PersistentStorage sd = new PersistentStorage("SD");

            string fileName = "\\SD\\app.hex";

            FileStream file = new FileStream(fileName, FileMode.Open, FileAccess.Read);

            // start update

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

                length = file.Read(buffer, 0, buffer.Length);
                SystemUpdate.ApplicationUpdate.Write(buffer, 0, length);

            } while (length == buffer.Length);


            // End update

            // Access the application


and the managed bootloader works like a charm :slight_smile:

Based on these results: IFU with gadgeteer must be done without gadgeteer (only native emx code) in managed bootloader. Perhaps something to add to the list for IFU on netmf 4.2?

After fixing the gadgeteer vs emx challenge, my next question is: Is it possible to update the update-partition in flash? There will be a need for updating it some point in time.

@ Skewworks: did you have the possibility to update the pyxisupdater in the field?

Yes that can be updated as well using a complete update bog course that means you have to update te firmware as well, but how often are you likely to need to update the updater?

So a full update does update both flash partitions even when the update software is running? Is there some kind of information stored in hex files so that the update mechanism knows where to restore different files?

It’s SystemUpdates that know where to put it. I’m not sure if there’s a header or a specific order it must be supplied in. You can refer to the docs or any of the examples.

@ skewworks:

Is the “bootloader.hex” file in the following piece of code the file which contains the pyxis2updater?

   string[] files;
            switch (SystemInfo.SystemID.Model)
                case 5: // Cobra
                    files = new string[] { "CLR.HEX", "CLR2.HEX", "Config.HEX", "pyxis2.hex", "bootloader.hex" };
                case 6: // Chipworks
                    files = new string[] { "ER_FLASH", "ER_CONFIG", "pyxis2.hex", "bootloader.hex" };
                default: // Unknown
                    bmp.DrawText("FAILED [0x" + SystemInfo.SystemID.Model + "]", bld, Color.White, 4 + TextWidth("INSTALLING UPDATES...", bld), y);

Yes. When you create the hex with MFDeploy you can supply the name. Pyxis2.hex is the main application, bootloader.hex is the update region.