Main Site Documentation

G120 IFU System.InvalidOperationException


#1

Hi,

I have an inconsistent issue with IFU on a Cobra III. We have 20 modules so far with the customer that we intend to update with IFU. When the time came for the first update, 2 of the 20 hung and would not recover. When I got them back, I found that they always hang when I try IFU. If I have the failing board bare (we usually have LCD, buttons, CAN/LIN transceivers on a daughter board), and am using a modified version of the standard IFU example (to load Application), and it still fails every time on the InFieldUpdate.FlashAndReset(). It fails with the following exception :

The thread ‘’ (0x2) has exited with code 0 (0x0).
#### Exception System.InvalidOperationException - CLR_E_INVALID_OPERATION (1) ####
#### Message:
#### GHI.Processor.InFieldUpdate::NativeFlashAndReset [IP: 0000] ####
#### GHI.Processor.InFieldUpdate::FlashAndReset [IP: 000f] ####
#### Program::FlashFirmware [IP: 0011] ####
#### Program::Main [IP: 000d] ####
A first chance exception of type ‘System.InvalidOperationException’ occurred in GHI.Hardware.dll
An unhandled exception of type ‘System.InvalidOperationException’ occurred in GHI.Hardware.dll

After this exception, the board will not boot again, as the application appears to be partially erased or corrupted.

It seems that these 2 Cobras always fail on IFU, although the main SW works fine if I load it via VS or Fez Config. The other 18 Cobras have no problem with IFU, even when I set them to loop the IFU continuously. They have had a second round of IFU with no further problems, so it does seem like these 2 boards are somehow pre-disposed to fail for some reason. All 20 were simply flashed with Fez Config when they arrived with a simple program to write a HW version number to the configuration memory,and then with the then-current version of the SW.

Does anyone know how I can find more details of what the exception might be here? Or is there a known failure rate in the IFU for the G120?

Thanks in advance

Nick

For reference, the modified IFU code I am using to test that gives me this exception is:

(I tried to get it formatted as code but failed :frowning: )

using GHI.Processor;
using System.IO;
using GHI.IO.Storage;

public class Program
{
public const int BLOCK_SIZE = 65535;

public static void Main()
{
    
    SDCard sd_card = new SDCard();

    // Mount the file system
    sd_card.Mount();

    FlashFirmware();
}

public static void FlashFirmware()
{
    // Reserve the memory needed to buffer the update.
    // A lot of RAM is needed so it is recommended to do this at the program start.
    //InFieldUpdate.Initialize(InFieldUpdate.Types.Firmware | InFieldUpdate.Types.Configuration);
    InFieldUpdate.Initialize(InFieldUpdate.Types.Application);

    // Start loading the new firmware on the RAM reserved in last step.
    // Nothing is written to FLASH In this stage. Power loss and failures are okay
    // Simply abort this stage any way you like!
    // Files can come from Storage, from network, from serial bus and any Other way.
    //LoadFile("\\SD\\Config.hex", InFieldUpdate.Types.Configuration);
    LoadFile("\\SD\\FlashTest.JNX1update", InFieldUpdate.Types.Application);
    //LoadFile("\\SD\\Firmware2.hex", InFieldUpdate.Types.Firmware); //Only if your device has two firmware files.

    // This method will copy The new firmware from RAM to FLASH.
    // This function will not return But will reset the system when done.
    // Power loss during Before this function resets the system quill result in a corrupted firmware.
    // A manual update will be needed if this method failed, due to power loss for example.
    InFieldUpdate.FlashAndReset();
}

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

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

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

}


#3

Does this only happen when doing type Application? Do Config or Firmware fail on their own as well?


#4

Looks like it does it with Config and Firmware…

I changed the code to :

public static void FlashFirmware()
{
    // Reserve the memory needed to buffer the update.
    // A lot of RAM is needed so it is recommended to do this at the program start.
    InFieldUpdate.Initialize(InFieldUpdate.Types.Firmware | InFieldUpdate.Types.Configuration);
    //InFieldUpdate.Initialize(InFieldUpdate.Types.Application);

    // Start loading the new firmware on the RAM reserved in last step.
    // Nothing is written to FLASH In this stage. Power loss and failures are okay
    // Simply abort this stage any way you like!
    // Files can come from Storage, from network, from serial bus and any Other way.
    LoadFile("\\SD\\Config.hex", InFieldUpdate.Types.Configuration);
    //LoadFile("\\SD\\FlashTest.JNX1update", InFieldUpdate.Types.Application);
    LoadFile("\\SD\\Firmware.hex", InFieldUpdate.Types.Firmware); //Only if your device has two firmware files.
    LoadFile("\\SD\\Firmware2.hex", InFieldUpdate.Types.Firmware); //Only if your device has two firmware files.

    // This method will copy The new firmware from RAM to FLASH.
    // This function will not return But will reset the system when done.
    // Power loss during Before this function resets the system quill result in a corrupted firmware.
    // A manual update will be needed if this method failed, due to power loss for example.
   
    InFieldUpdate.FlashAndReset();
} 

and got

The thread ‘’ (0x2) has exited with code 0 (0x0).
#### Exception System.InvalidOperationException - CLR_E_INVALID_OPERATION (1) ####
#### Message:
#### GHI.Processor.InFieldUpdate::NativeFlashAndReset [IP: 0000] ####
#### GHI.Processor.InFieldUpdate::FlashAndReset [IP: 000f] ####
#### Program::FlashFirmware [IP: 0022] ####
#### Program::Main [IP: 000d] ####
A first chance exception of type ‘System.InvalidOperationException’ occurred in GHI.Hardware.dll
An unhandled exception of type ‘System.InvalidOperationException’ occurred in GHI.Hardware.dll

Is it worth me trying each config and firmware hex on their own - would that tell you anything more?

Thanks

Nick


#5

I do something similar and haven’t seen this failure. The only difference I see is that I have

InFieldUpdate.Initialize(InFieldUpdate.Types.Application | InFieldUpdate.Types.Configuration | InFieldUpdate.Types.Firmware);

instead of


#6

Thanks for the replies, guys.

I just matched the types with the files I was flashing. I assume it is okay to initialise more than we use.

To be sure, I added InFieldUpdate.Types.Application to the Initialize and only flashed the config.hex, but I get the same exception still.

However, 18 Cobras are happy with this code and 2 fail 100%, so I assume that the failing Cobras are in some unhappy state internally in some way, rather than a code issue. Is there anything I can do to health-check them?
I am just ordering 200 for the next batch, and I am hoping not to have the same ratio of issues. Is there anything I could have done to these parts via Fez Config to upset them like this? I am sure that I did the same hex deployment to them all, but maybe I didn’t leave something long enough at some point…? Either that, or those Cobras have an IFU-related fault :frowning:

Nick


#7

It’s hard to say without looking at them. The two you have that fail, can you enter the low level bootloader and erase them, use it to reload TinyBooter, then use MFDeploy to load the firmware and your application. See if they still give the same exception then. Which firmware version are you running?


#8

Hi John,

Coincidentally, I have just done almost exactly that! I used Fez Config to do the TinyBooter update which reloaded 4.3.8.1 firmware

I Deployed from VS rather than MFDeploy, but got the exception while flashing just the config.hex

The thread ‘’ (0x2) has exited with code 0 (0x0).
#### Exception System.InvalidOperationException - CLR_E_INVALID_OPERATION (1) ####
#### Message:
#### GHI.Processor.InFieldUpdate::NativeFlashAndReset [IP: 0000] ####
#### GHI.Processor.InFieldUpdate::FlashAndReset [IP: 000f] ####
#### Program::FlashFirmware [IP: 0012] ####
#### Program::Main [IP: 000d] ####
A first chance exception of type ‘System.InvalidOperationException’ occurred in GHI.Hardware.dll
An unhandled exception of type ‘System.InvalidOperationException’ occurred in GHI.Hardware.dll

Does that give you the info you are after?

Thanks

Nick


#9

To be safe, if possible, can you update TinyBooter using TeraTerm and deploy the firmware with MFDeploy? Just to remove FEZ Config from the equation.


#10

Hi John,

Tinybooter uploaded via TeraTerm…
image

Then I deployed the app via MFDeploy. That test code should have continuously flashed and rebooted, but it appeared to just hang. I then deployed the simple test code again via VS and the exception is still happening.

Nick


#11

It sounds possibly like a hardware problem preventing loading of valid firmwares through IFU. Hard to say exactly without being able to reproduce it here.