I use GHI’s Tool to produce the ManagedApp.hex. (see picture 1), After connecting EMX I click the “Creat” button and save the ManagedApp.hex in my computer, am I right?
I saved Firmware.hex, Firmware2.hex, Config.hex, Firmware.sig, Firmware2.sig, Config.sig and ManagedApp.hex in SD card, and plug into my EMX board
I have written a button1 handler to implement the IFD function as follow:
public static void Main()
{
............................................................................
............................................................................
//Button Handler
InterruptPort IntButton1 = new InterruptPort(EMX.Pin.IO21, false, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeLow);
IntButton1.OnInterrupt += new NativeEventHandler(IntButton_OnInterrupt1);
}
static void IntButton_OnInterrupt1(uint port, uint state, DateTime time)
{
Debug.Print("Button1 Pressed");
try
{
// Initialize System Update, passing in what areas you want to update
// Optionally select what regions to update
SystemUpdate.Initialize(SystemUpdate.SystemUpdateType.Config | SystemUpdate.SystemUpdateType.Deployment | SystemUpdate.SystemUpdateType.Firmware);
// Load in the 1st firmware file
LoadDataFromSD(@ "SD\Firmware", SystemUpdate.SystemUpdateType.Firmware);
// Load in the 2nd firmware file
LoadDataFromSD(@ "SD\Firmware2", SystemUpdate.SystemUpdateType.Firmware);
// Load in the Configuration file
LoadDataFromSD(@ "SD\Config", SystemUpdate.SystemUpdateType.Config);
// Load in your newly created application
LoadDataFromSD(@ "SD\ManagedApp.hex", SystemUpdate.SystemUpdateType.Deployment);
// Check to see if you can update
if (SystemUpdate.CanUpdate)
{
// If we can update, tell the firmware to copy the new files to flash, and restart.
// After this restart, your newly loaded firmware files, configuration, and application will be on the board.
SystemUpdate.FlashAndReset();
}
}
catch (Exception e)
{
throw new Exception("Fail when updating data " + e.ToString());
}
}
After rebuilding project and running ok, I pressed button1 and got a window as in picture2
why I can’t updata the "ManagedApp.hex "?
Thank you, I have specified extension of the files, und run my project. It seems that only Firmware.hex is updated, and project stopted and gave me the Exception.
I got the debug information as follow:
Button1 Pressed
#### Exception System.InvalidOperationException - CLR_E_INVALID_OPERATION (3) ####
#### Message:
#### GHI.Premium.IO.PersistentStorage::.ctor [IP: 0000] ####
#### FEZ_Cobra_Workhard.Program::MoundSDCard [IP: 0013] ####
#### FEZ_Cobra_Workhard.Program::IntButton_OnInterrupt1 [IP: 000b] ####
A first chance exception of type 'System.InvalidOperationException' occurred in GHI.Premium.IO.dll
Can't create PersistentStorage
Loading file SD\Firmware.hex, block 0/132
Loading file SD\Firmware.hex, block 1/132
Loading file SD\Firmware.hex, block 2/132
Loading file SD\Firmware.hex, block 3/132
Loading file SD\Firmware.hex, block 4/132
.....................................................................
....................................................................
Loading file SD\Firmware.hex, block 128/132
Loading file SD\Firmware.hex, block 129/132
Loading file SD\Firmware.hex, block 130/132
Loading file SD\Firmware.hex, block 131/132
GC: 18msec 4380348 bytes used, 2959320 bytes available
Type 0F (STRING ): 2544 bytes
Type 11 (CLASS ): 12924 bytes
Type 12 (VALUETYPE ): 684 bytes
Type 13 (SZARRAY ): 4860 bytes
Type 03 (U1 ): 1500 bytes
Type 04 (CHAR ): 444 bytes
Type 07 (I4 ): 132 bytes
Type 0F (STRING ): 768 bytes
Type 11 (CLASS ): 1932 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 2959320 bytes
Type 16 (CACHEDBLOCK ): 264 bytes
Type 17 (ASSEMBLY ): 27000 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 1548 bytes
Type 1C (DELEGATELIST_HEAD ): 96 bytes
Type 1D (OBJECT_TO_EVENT ): 1320 bytes
Type 1E (BINARY_BLOB_HEAD ): 4312536 bytes
Type 1F (THREAD ): 4224 bytes
Type 20 (SUBTHREAD ): 528 bytes
Type 21 (STACK_FRAME ): 4824 bytes
Type 22 (TIMER_HEAD ): 72 bytes
Type 23 (LOCK_HEAD ): 60 bytes
Type 24 (LOCK_OWNER_HEAD ): 24 bytes
Type 25 (LOCK_REQUEST_HEAD ): 108 bytes
Type 27 (FINALIZER_HEAD ): 1080 bytes
Type 31 (IO_PORT ): 1368 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4140 bytes
GC: performing heap compaction...
#### Exception System.IO.IOException - CLR_E_INVALID_DRIVER (3) ####
#### Message:
#### Microsoft.SPOT.IO.NativeIO::GetAttributes [IP: 0000] ####
#### System.IO.FileStream::.ctor [IP: 005c] ####
#### System.IO.FileStream::.ctor [IP: 000a] ####
#### FEZ_Cobra_Workhard.Program::LoadDataFromSD [IP: 0008] ####
#### FEZ_Cobra_Workhard.Program::IntButton_OnInterrupt1 [IP: 0022] ####
A first chance exception of type 'System.IO.IOException' occurred in Microsoft.SPOT.IO.dll
A first chance exception of type 'System.IO.IOException' occurred in System.IO.dll
#### Exception System.Exception - 0x00000000 (3) ####
#### Message: Fail when updating data System.IO.IOException
#### FEZ_Cobra_Workhard.Program::IntButton_OnInterrupt1 [IP: 0055] ####
A first chance exception of type 'System.Exception' occurred in FezCobraWorkhard.exe
An unhandled exception of type 'System.Exception' occurred in FezCobraWorkhard.exe
Additional information: Fail when updating data System.IO.IOException
Hmmm, it’s interesting that the IFU barfs at the last block (block 131/132). On my G120, IFU fails if the array being fed to SystemUpdate.Load() is too small, which usually happens on the final block, since this is where the remainder goes.
Hello, it looks like that exception comes from “reading from SD”, check your file name, debug step by step so you can see what file cause exception, not IFU, try another SD card if needed.
In case IFU report the file size too small, it was fixed and be coming at next release.
But right now, you can fix it by make sure that every block (include last block) is >= 46. it is easy by re-define your block size.
@ workhard10 - If it’s the block size problem, another alternative perhaps is to add some dummy print statements in your managed code and vary the length of the string(s) that they print until you find a suitable hex file length that doesn’t make IFU stop. Just conjecture though. I haven’t tried this yet.
If you’ve been following the example, your block size will probably be 10240 bytes. To determine if it’s the length problem, I’d take the modulus [(number of bytes in hex file) % 10240] to get the remainder. If the remainder is less than 46, the length issue may be what you’re encountering.
thank you for your help! I have checked my software, it seems that it’s my SD card define problem. I have made some changes and now the Firmware.hex, Firmware2.hex, Config.hex, ManagedApp.hex are updated.
but new problem happens, the project stopt. I can see as follow from the Output window:
Button1 Pressed
Loading file SD\Firmware.hex, block 0/132
Loading file SD\Firmware.hex, block 1/132
Loading file SD\Firmware.hex, block 2/132
...........................................
...........................................
Loading file SD\Firmware.hex, block 128/132
Loading file SD\Firmware.hex, block 129/132
Loading file SD\Firmware.hex, block 130/132
Loading file SD\Firmware.hex, block 131/132
GC: 27msec 4380288 bytes used, 2959380 bytes available
Type 0F (STRING ): 2544 bytes
Type 11 (CLASS ): 12888 bytes
Type 12 (VALUETYPE ): 684 bytes
.......................................
......................................
Type 27 (FINALIZER_HEAD ): 1056 bytes
Type 31 (IO_PORT ): 1368 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4140 bytes
GC: performing heap compaction...
Loading file SD\Firmware2.hex, block 0/302
Loading file SD\Firmware2.hex, block 1/302
Loading file SD\Firmware2.hex, block 2/302
......................................
....................................
Loading file SD\Firmware2.hex, block 298/302
Loading file SD\Firmware2.hex, block 299/302
Loading file SD\Firmware2.hex, block 300/302
Loading file SD\Firmware2.hex, block 301/302
GC: 15msec 4380024 bytes used, 2959644 bytes available
Type 0F (STRING ): 2544 bytes
Type 11 (CLASS ): 12888 bytes
Type 12 (VALUETYPE ): 684 bytes
...................................................
.................................................
Type 25 (LOCK_REQUEST_HEAD ): 108 bytes
Type 27 (FINALIZER_HEAD ): 1056 bytes
Type 31 (IO_PORT ): 1368 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4140 bytes
GC: performing heap compaction...
GC: 8msec 4380048 bytes used, 2959620 bytes available
Type 0F (STRING ): 2508 bytes
Type 11 (CLASS ): 12888 bytes
Type 12 (VALUETYPE ): 636 bytes
..........................................................
..........................................................
Type 25 (LOCK_REQUEST_HEAD ): 108 bytes
Type 27 (FINALIZER_HEAD ): 1056 bytes
Type 31 (IO_PORT ): 1368 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4140 bytes
GC: performing heap compaction...
Loading file SD\ManagedApp.hex, block 0/454
Loading file SD\ManagedApp.hex, block 1/454
Loading file SD\ManagedApp.hex, block 2/454
...........................................................................
...........................................................................
Loading file SD\ManagedApp.hex, block 451/454
Loading file SD\ManagedApp.hex, block 452/454
Loading file SD\ManagedApp.hex, block 453/454
GC: 18msec 4380024 bytes used, 2959644 bytes available
Type 0F (STRING ): 2544 bytes
Type 11 (CLASS ): 12888 bytes
Type 12 (VALUETYPE ): 684 bytes
Type 13 (SZARRAY ): 4860 bytes
Type 03 (U1 ): 1500 bytes
Type 04 (CHAR ): 444 bytes
Type 07 (I4 ): 132 bytes
Type 0F (STRING ): 768 bytes
Type 11 (CLASS ): 1932 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 2959644 bytes
Type 17 (ASSEMBLY ): 27000 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 1548 bytes
Type 1C (DELEGATELIST_HEAD ): 96 bytes
Type 1D (OBJECT_TO_EVENT ): 1320 bytes
Type 1E (BINARY_BLOB_HEAD ): 4312536 bytes
Type 1F (THREAD ): 4224 bytes
Type 20 (SUBTHREAD ): 528 bytes
Type 21 (STACK_FRAME ): 4824 bytes
Type 22 (TIMER_HEAD ): 72 bytes
Type 23 (LOCK_HEAD ): 60 bytes
Type 24 (LOCK_OWNER_HEAD ): 24 bytes
Type 25 (LOCK_REQUEST_HEAD ): 108 bytes
Type 27 (FINALIZER_HEAD ): 1056 bytes
Type 31 (IO_PORT ): 1368 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4140 bytes
GC: performing heap compaction...
I thought the borad will be restarted and ran my updated new application. but it stopts now,
I don’t know what’s going on… the the T35 display show me nothing…
I have used “EMX Updater” reflashed my EMX and tried some times. I find that the program stopts at “SystemUpdate.FlashAndReset();”.
SystemUpdate.FlashAndReset();
It seems that the flash can not be flashed and reseted…
Can you have Cobra/EMX or spider and try the IFU at you kits? to see if the same problem happens?
the follow is the button handler for IFU function:
static void IntButton_OnInterrupt1(uint port, uint state, DateTime time)
{
Debug.Print("Button1 Pressed");
try
{
// Initialize System Update, passing in what areas you want to update
// Optionally select what regions to update
SystemUpdate.Initialize(SystemUpdate.SystemUpdateType.Config | SystemUpdate.SystemUpdateType.Deployment | SystemUpdate.SystemUpdateType.Firmware);
// Load in the 1st firmware file
LoadDataFromSD(@ "SD\Firmware.hex", SystemUpdate.SystemUpdateType.Firmware);
// Load in the 2nd firmware file
LoadDataFromSD(@ "SD\Firmware2.hex", SystemUpdate.SystemUpdateType.Firmware);
// Load in the Configuration file
LoadDataFromSD(@ "SD\Config.hex", SystemUpdate.SystemUpdateType.Config);
// Load in your newly created application
LoadDataFromSD(@ "SD\ManagedApp.hex", SystemUpdate.SystemUpdateType.Deployment);
Debug.Print("Flash And Reset waiting.....");
// Check to see if you can update
if (SystemUpdate.CanUpdate)
{
Debug.Print("Can Update.....");
// If we can update, tell the firmware to copy the new files to flash, and restart.
// After this restart, your newly loaded firmware files, configuration, and application will be on the board.
SystemUpdate.FlashAndReset();
Debug.Print("Flash And Reset");
}
}
catch (Exception e)
{
throw new Exception("Fail when updating data " + e.ToString());
}
}
the follow is debug output:
................................
....................................
............................
Loading file SD\ManagedApp.hex, block 448/454
Loading file SD\ManagedApp.hex, block 449/454
Loading file SD\ManagedApp.hex, block 450/454
Loading file SD\ManagedApp.hex, block 451/454
Loading file SD\ManagedApp.hex, block 452/454
Loading file SD\ManagedApp.hex, block 453/454
GC: 19msec 4380024 bytes used, 2959644 bytes available
Type 0F (STRING ): 2544 bytes
Type 11 (CLASS ): 12888 bytes
Type 12 (VALUETYPE ): 684 bytes
Type 13 (SZARRAY ): 4860 bytes
Type 03 (U1 ): 1500 bytes
Type 04 (CHAR ): 444 bytes
Type 07 (I4 ): 132 bytes
Type 0F (STRING ): 768 bytes
Type 11 (CLASS ): 1932 bytes
Type 12 (VALUETYPE ): 84 bytes
Type 15 (FREEBLOCK ): 2959644 bytes
Type 17 (ASSEMBLY ): 27000 bytes
Type 18 (WEAKCLASS ): 48 bytes
Type 19 (REFLECTION ): 24 bytes
Type 1B (DELEGATE_HEAD ): 1548 bytes
Type 1C (DELEGATELIST_HEAD ): 96 bytes
Type 1D (OBJECT_TO_EVENT ): 1320 bytes
Type 1E (BINARY_BLOB_HEAD ): 4312536 bytes
Type 1F (THREAD ): 4224 bytes
Type 20 (SUBTHREAD ): 528 bytes
Type 21 (STACK_FRAME ): 4824 bytes
Type 22 (TIMER_HEAD ): 72 bytes
Type 23 (LOCK_HEAD ): 60 bytes
Type 24 (LOCK_OWNER_HEAD ): 24 bytes
Type 25 (LOCK_REQUEST_HEAD ): 108 bytes
Type 27 (FINALIZER_HEAD ): 1056 bytes
Type 31 (IO_PORT ): 1368 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 4140 bytes
GC: performing heap compaction...
Flash And Reset waiting.....
Can Update.....
The function is FLASHANDRESET, it means Flash then Reset, when the board is being programming, it takes (I don’t remember exactly) few minutes. Do not reset by your hand, the board will be reset automatically.
try to update Config or Deployment only first to get completely understand how IFU work then you can try with all.
I mean you won’t see any change in screen even Flashandreset is running. When this function is done, the board will be reset. Flashandreset will take few minutes depends on how big your data is.
I know why my In-Field Update was always not successful now.
I have 6 thread tasks in my project, one of the thread tasks is watchdog.
I must stop the watch dog before updating the new application. somethings like as follow:
// We don't need Watchdog anymore, we have to keep resetting the timeout
GHI.Premium.Hardware.LowLevel.Watchdog.Enable(GHI.Premium.Hardware.LowLevel.Watchdog.MAX_TIMEOUT);
WDTCounterReset.Abort();
try
{
Debug.Print("In Field Upfata beginn......");
// Initialize System Update, passing in what areas you want to update
// Optionally select what regions to update
SystemUpdate.Initialize(SystemUpdate.SystemUpdateType.Config | SystemUpdate.SystemUpdateType.Deployment | SystemUpdate.SystemUpdateType.Firmware);
// Load in the 1st firmware file
LoadDataFromSD(@ "SD\Firmware.hex", SystemUpdate.SystemUpdateType.Firmware);
..............................................................
.................................................................
if (SystemUpdate.CanUpdate)
{
Debug.Print("Can updata......... wait flashing and reset");
// If we can update, tell the firmware to copy the new files to flash, and restart.
// After this restart, your newly loaded firmware files, configuration, and application will be on the board.
SystemUpdate.FlashAndReset();
Debug.Print("wait flashing and reset ready!");
}
}
catch (Exception e)
{
throw new Exception("Fail when updating data " + e.ToString());
}
Thread.Sleep(Timeout.Infinite);
If the watchdog is not be stopped, the flash of EMX can not be flashed and reset.
when the board is being programming, it takes (I don’t remember exactly) few minutes. Do not reset by your hand, the board will be reset automatically.