Main Site Documentation

Aborting a SystemUpdate halfway through


We have to receive an application update over a serial interface.
The application update cannot be stored in memory so we have to write
to the ApplicationUpdate as we receive the data.

We can add a CRC checksum to every packet we receive,
but what if the data is in fact corrupt.

This means we may already have written 5 pieces of data to the SystemUpdate.ApplicationUpdate,
and at this point we need to abort because the data is corrupt anyway.

How do we back out of this, in order not to corrupt the main application,
or is the main application already corrupted at this point?

And if the main application is corrupted,
is there a way to make sure the Panda will automatically fallback to the bootloader mode?
(Without starting the bootloader mode at startup every time, even if the application is valid)

(Another option, that wouldn’t fully fix the problem above is that I simply send an error
to the client and then reset the device so that it will load in bootloader mode again, until
the update has actually been completed correctly)

Are there any suggestions for doing an update like this?


I don’t think you can abort in the middle like that, but you can write in chunks. So why not send in chunks small enough to check CRC first, then if it passes write it and wait for the next one.


Well I do reply in chunks and my idea was to check the crc,
but it seems (although it is very poorly documented) that the write has some kind of checking

If you try to send a wrong file you get a an ArgumentException immediatly
if one of the following writes contains invalid data you get it as well

Although I seem to be getting a s****load of argument exceptions during the process


USBizi has very little memory so why you load goes directly on flash and so, no you can’t abort.

You will need to put the chip into loader mode to write the loader and put in firmware mode to load firmware and then your final work will be in switching back and forth to load firmware in-filed. This requires full understanding of the system, ie reading the documentation slowly :slight_smile: and understanding the whole boot-loader/application concept.


I’m reading and following the code from the chm file. The section on SystemUpdate class.
I have read it over and over again… it does not mention an Argument exception anywhere…

[quote]Updating The Main Application Only (ApplicationUpdate)
Using this option, you can make the device always updatable and fail safe is case of bugs or update failures. Once the bootloader mode is enabled, it will always be active and you can update as necessary until done and then access the main application again using SystemUpdate.AccessApplication.
The update is done simply be passing the application file to SystemUpdate.ApplicationUpdate.Write.

Apparently it’s not as simple as described here?

It would really help if you could tell me under what conditions the write method throws an Argument exception.


Did you enable the loader mode and reset the device the verified that you ate in loader mode so you can do a write?

if (!(SystemUpdate.GetMode() == SystemUpdate.SystemUpdateMode.Bootloader))
                throw new InvalidOperationException("Not in bootloader mode");

Data is received in chunks, the write method writes them,
somtimes 5 chunks, sometimes 10, sometimes X and then it will
just throw an ArgumentException randomly…

    #### Exception System.ArgumentException - 0xfd000000 (1) ####
    #### Message: 
    #### GHIElectronics.NETMF.System.SystemUpdate+ApplicationUpdate::Write [IP: 0000] ####
    #### Vialis.Led.PrismaProxy.Bootloader.Bootloader::.ctor [IP: 00c8] ####
    #### Vialis.Led.PrismaProxy.Bootloader.Bootloader::Main [IP: 0004] ####
A first chance exception of type 'System.ArgumentException' occurred in GHIElectronics.NETMF.SystemUpdate.dll

Since I have on idea what it means, I have no idea how to respond to the problem properly…
If it means the data is corrupted, that’s pretty odd because there is no reason why the data should get corrupted…

PS: If I wasn’t in bootloader mode, the proper exception when trying to write would be an InvalidOperationException. (and if I’m not mistaken, that’s what it throws when you are not in bootloader mode)