IFU - Cannot find any entrypoint!

FEZ Spider - 4.3SDK 2015 R1 Pre-release 2.

I’m having some trouble with the In-Field update. I’ve created a .hex file with MFDeploy. I’m able to load that hex file to the board through MFDeploy and the app works fine so I know its a good hex file. I saved the app to the SD card as “app.hex”.

When I try to load the same hex file using InFieldUpdate (using the example at https://www.ghielectronics.com/docs/147/in-field-update) everything appears to go fine but I get an error when the board resets “Cannot find any entrypoint!”

I’ve provide code samples but its pretty much a copy and paste of the example. Only difference is I used the InFieldUpdate.Types.Application because I don’t want or need to update the firmware or config.

Relevant code samples:



        private const int BlockSize = 65536;

        private const string UpdateAppFilename = @ "SD\app.hex";

        private void PerformInFieldUpdate()
        {
            Logger.Log(this.ToString(), "Updating Software");
            GHI.Processor.InFieldUpdate.Initialize(GHI.Processor.InFieldUpdate.Types.Application);

            LoadFile(UpdateAppFilename, GHI.Processor.InFieldUpdate.Types.Application);

            try
            {
                GHI.Processor.InFieldUpdate.FlashAndReset();
            }
            catch (Exception ex)
            {
                Logger.Log(this.ToString(), string.Concat("The update process failed. Error: ", ex.Message));
                Microsoft.SPOT.Hardware.PowerState.RebootDevice(false);
            }
        }

        private static void LoadFile(string filename, GHI.Processor.InFieldUpdate.Types type)
        {
            using (var stream = new FileStream(filename, FileMode.Open))
            {
                var data = new byte[BlockSize];

                for (int i = 0; i < stream.Length / BlockSize; i++)
                {
                    stream.Read(data, 0, BlockSize);
                    GHI.Processor.InFieldUpdate.Load(type, data, BlockSize);
                }

                stream.Read(data, 0, (int)stream.Length % BlockSize);
                GHI.Processor.InFieldUpdate.Load(type, data, (int)stream.Length % BlockSize);
            }
        }

MFDeploy output after the update is applied and the board reboots:

Both, the original app and the new app, must be using he same assemblies for IFU to work. If they are not, the the update must include the new firmware as well.

For testing, just try it on the same device with the same SDK. Make 2 apps, one that blinks LED slow and one that blinks fast, then load using IFU. You should be able to load one on top of the other, back and forth, and observe the LED to make sure the update did happen.

The app I’m loading with IFU is actually just the exact same app that is running. I used MFDeploy to copy the app and I’m just using IFU to re-apply the exact same application. So there are no differences at all - references or otherwise.

@ PhilH - Then there is no reason why it wouldn’t work , except the file is corrupted.

The file isn’t corrupt. The file I coped to the SD card is good because I can load that exact file to the board through MFDeploy and I do not have the “Cannot find any entrypoint!” error.

Is the process I’m using correct? In the example code for In-Field update (https://www.ghielectronics.com/docs/147/in-field-update) the example code is loading the types “Firmware” and “Configuration”. In my code I’m loading the type “Application” which I thought is what I get from MF Deploy when I do the “Create Application Deployment”. Is that hex file created by MF Deploy really a “Firmware” type and not an “Application” type?

I’m not ruling out that I’ve possibly done something wrong, but I do know that the hex file is not corrupt. I’m able to reload it to the board via MF Deploy and I don’t have the error “Cannot find any entrypoint!”

@ PhilH -

How large is your application?

I just created simple app and tried on 4.3.7.9, it works fine for me (I don’t think 4.3.7.8 (R2) has different IFU)

public static void Main()
        {
            while (true)
            {
                System.Threading.Thread.Sleep(500);
                Debug.Print("I am from IFU ");
            }
            
        }

[quote]
In my code I’m loading the type “Application” which I thought is what I get from MF Deploy when I do the “Create Application Deployment”. Is that hex file created by MF Deploy really a “Firmware” type and not an “Application” type?[/quote]
The hex file does not contain any information about “App” or “Firmware”. You can use FEZ Config -> Deployment (Advande) -> Create HEX file. Compare 2 output file, if they are identical then nothing wrong with hex file. If they are different, you did something wrong and use the one by FEZ Config.

The application file size is 684 KB (700,416 bytes) on disk.

FEZ Config does output different hex files than MF Deploy. They’re the same size as the file created by MF Deploy but slightly different in the bytes they contain.

Either HEX seems to work though. After the IFU leaves the board in this state where I get the error “Cannot find any entrypoint!” I can reload either HEX file (the MF Deploy or FEZ Config) to the board and the software loads and works.

@ PhilH -

Try small one to see what happens, please
Did you create any key when create hex file?

I did just this. It works. The hex file size on these apps is 412 KB (421,888 bytes).

I noticed when these two blink the LED apps are doing the IFU process it takes much longer than it does with my other application which cannot successfully IFU. In the other application which fails the update process goes real fast between when the debug shows that its starting the update and then when the board reboots. Then I get the “Cannot find any entrypoint!” error. Its almost so quick I wonder if the IFU is only erasing the existing application and not loading the new application.

Does IFU have a file size limit?

There is no limit but maybe the hex file is corrupted and ifu is ignoring it? I am guessing.

I can load the hex through both FEZ Config and MF Deploy. I’m pretty sure the hex is fine.

Not sure if IFU is ignoring the hex, but it does corrupt the existing application since when the board reboots it does not load the application that used to be on it. The boot just fails at “Cannot find any entrypoint!” and the only solution to get the board to boot again is to either reload the application using the hex file I provided to the IFU or re-deploy from visual studio.

SO the IFU does work with blink LED programs.

If there is something odd about my other hex file that doesn’t work with IFU would FEZ Config or MF Deploy complain that it was corrupt? Because FEZ Config and MF Deploy don’t raise any errors and they both successfully load the hex file on the board and the application works just fine after that.

The file is right, but I think it is not being transferred and the corruption is there, not inn the file.

I follow you. So something is corrupting it in the process of reading it from the SD card during the LoadFile step?

@ PhilH - that is my guess

For testing a large hex file, you can test with hex firmware files which are very bigger than your app hex file. It should work fine.
Need to change IFU type when initialize and loading.

Also, if there is no secret with your hex file, we are willing to take it for testing in our side.

:wall:

Rookie mistake. The firmware and the IFU was working the whole time. I had the watchdog set at 15 seconds. This was causing the board to restart during the IFU update.

One follow up question though. If I do up the IFU update including the Config.hex, Firmware.hex, and Firmware2.hex files in addition to the app.hex will that allow me also upgrade the device to newer versions of the firmware & sdk as they become available? For example when the 2015 SDK release is final could I update to that using the IFU process? (And beyond? Like NETMF 4.4 when it is available?)

Thanks,

Phil

In most cases yes. Tinybooter will not update and so you can only update release with compatible timybooter.

@ PhilH -

4.3.7.7, 4.3.7.8 and 4.3.7.9 use same TinyBooter, if you have 4.3.7.8 installed then no need to update TinyBooter when upgrade to 4.3.7.9.
So far no change Tinybooter unless there is bug.