Is IFU implemented in G400? I cannot make it working, if I call SystemUpdate.Load I get “Exception System.ArgumentException - 0xfd000000 (18)”…
Latest firmware?
Yup…
Guys?..
Can you check your argument or show us your code, pls?
Made a few tests… If I run empty project with only this code:
public static void Main() {
Thread.Sleep(5000);
Debug.Print("Initializing");
SystemUpdate.Initialize(SystemUpdate.SystemUpdateType.Deployment);
Debug.Print("Loading 2560 bytes");
var array1 = new byte[2560];
for (int i = 0; i < 100; i++) {
Debug.Print("Sending " + i);
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Deployment, array1, array1.Length);
}
SystemUpdate.Abort();
while (true) {
Thread.Sleep(100);
}
}
It appears to be working. However, in my big application, it fails. Here’s a simplified excerpt:
if (SystemUpdate.CurrentSystemUpdateStatus==SystemUpdate.SystemUpdateStatus.Inactive) SystemUpdate.Initialize(SystemUpdate.SystemUpdateType.Deployment);
Debug.Print("IFU add" +value.Length+" bytes");
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Deployment, value, value.Length);
break;
The output looks like:
IFU add 2560 bytes
IFU add 2560 bytes
#### Exception System.ArgumentException - 0xfd000000 (18) ####
#### Message:
#### GHI.Premium.System.SystemUpdate::SystemUpdateLoad [IP: 0000] ####
#### GHI.Premium.System.SystemUpdate::Load [IP: 0085] ####
#### Titan.Program::SetLocalRegister [IP: 1260] ####
#### Titan.Program::SetRegisterCommandsReceivedEventHandler [IP: 00b3] ####
#### LightConversion.Protocols.Yadp.SetRegisterCommandsReceivedEventHandler::Invoke [IP: 0000] ####
#### LightConversion.Protocols.Yadp.YadpProvider::ProcessRawData [IP: 021b] ####
#### Titan.Program+<>c__DisplayClass19::<Main>b__e [IP: 001b] ####
#### LightConversion.Micro.DataReceivedEventHandler::Invoke [IP: 0000] ####
#### Titan.ExternalConnections::localEventHandler [IP: 000a] ####
#### LightConversion.Micro.DataReceivedEventHandler::Invoke [IP: 266ed690] ####
#### LightConversion.Micro.Net.LanConnection3::<Enable>b__6 [IP: 00e0] ####
A first chance exception of type 'System.ArgumentException' occurred in GHI.Premium.SystemUpdate.dll
An unhandled exception of type 'System.ArgumentException' occurred in GHI.Premium.SystemUpdate.dll
It always fail on second call to SystemUpdate.Load(). could it be some threading problem, or something with RAM?..
@ Simon from Vilnius -
-
Not a Ram issue because it will raise an exception if there is not enough RAM when Initialize
-
There are 3 things can cause an argument exception:
- Size is zero
- 2 first characters are not S3 or S7
- Checksum is wrong
I am confused between big application that will call IFU functions, or big hex deployment file that will be called / loaded by IFU.
Oh, so “S3” or “S7” are coming from .HEX file? That means blocks passed to SystemUpdate.Load() cannot be of any size, it must be a multiple of lines in Hex file?..
What checksum?..
Yeb
That is why I don’t understand
Debug.Print("Loading 2560 bytes");
var array1 = new byte[2560];
for (int i = 0; i < 100; i++) {
Debug.Print("Sending " + i);
SystemUpdate.Load(SystemUpdate.SystemUpdateType.Deployment, array1, array1.Length);
}
array will be zero at all but you said it works :think:
No, can be any size, but must have correct format
as I know it should be like this:
https://www.ghielectronics.com/community/forum/topic?id=11482&page=2
But I am wondering, how did you get the hex deployment file, it should have correct format if use MFDeploy or FezConfig tool.
I guess the checksum of zeros is a zero…
Could you please define “Correct format”? Starting with “S3” or “S7”? Any other requirements? What about “\r\n” characters inside Hex file? Shall I remove them?
Yes, I use FezConfig.
@ Simon from Vilnius -
No, an exception will be raised if there is no S3 or S7 while all of them are zero :think:
I think
Edit:
S → 3/7 → datacount-> address 4 bytes → data0-> data1 → … ->dataN->CS
and CS = ~(dataCount + add[0] + add[1] +… add[3] + data[0] + data[1] +…data[dataCount -2]);
If I load one line (46 bytes, “\r\n” removed) per .Load() call, it does not crash, but I have 22000 lines and the process stops somewhere in the middle (could be a bug my code, though). If I try anything longer than 46 bytes, SystemUpdate.Load() raises the same exception on the second call.
Something is really flawed here. Please advise what should I try next?..
@ Simon from Vilnius -
if you change anything in a line, (add more than 46 bytes…) you need to change header and cs.
You can write a c# application to check all format on each line correct or not. It is not difficult.
So now you say I cannot load more than 46 bytes per call? So how does than an example here http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation%20v4.2/Premium/Index.html works? It’s loading 10240 bytes per call… Or shall I reformat the Hex file so it contains 1 line?!
@ Simon from Vilnius -
I thought you wanted to try one line, ;D
Edit:
Anyway, open your hex file, except for few last lines, there should be alway 46 bytes per each line, try a block with 46 bytes, so we can know what line cause exception
22000*21 = 462Kb,not too big, I don’t think this relates to RAM
Sorry guys I really don’t get this type of humour. I use GHI’s tool (FezConfig), I use GHI’s update functions, yet I still have to write my own program to convert image using a well-hidden procedure so one GHI code could talk to another GHI code? Isn’t that [em]your[/em] job?..
I’ve tried that, it was no exception, it just silently stopped after a few hundred calls. Not sure if that’s your code that is failing or mine. I’ll try again.
If you can give us a sample project that we can reproduce here, we will do it and give you an best answer as we can,
Otherwise, we try to guess or get more information about the bug from you.
While my update procedure is still running (I expect at least half an hour to send all 22000 lines), why not start by checking why SystemUpdate does not complain when I load total nonsense, as per reply #5? Can you reproduce it?
@ Simon from Vilnius -
I just made a try with post#5, yes, there is no exception when all data is zero, actually it returns a FALSE value, but because Load function is not a return function so we don’t see any thing
It will be a minor change then an exception will be raised, but this is not a bug that can effect to what we talking.