SystemUpdate.Load() minimum required block size?

If I’m using SystemUpdate.Load() like so:


SystemUpdate.Load(SystemUpdate.SystemUpdateType.Deployment, data, data.Length);

Does the “data” byte-array have a minimum required size? When data happens to be 16 bytes long, for example, I get an “Invalid param. Data is too small” exception (screenshot). Is this normal?

@ andre - LOL, I wish I had an app size of only 16 bytes!

Imagine this setup from GHI’s SystemUpdate Class documentation. To paraphrase:

  • We are reading the application hex file from some source. In the example, the source is a SD card.

  • We are using SystemUpdate.Load() to load the hex file in block increments. The block size in the example is 10 * 1024 bytes = 10240 bytes long.

  • Finally, at the very end, there will likely be a remainder. This remainder is (ApplicationSize modulo 10240). We still need to use Load() to load the remainder.

So if my application size is 40976 bytes, I will end up with a 16-byte remainder. And this will throw an exception once I finally Load() this portion.

If this is not intentional behavior, it can actually be quite insidious. Imagine in-field update working for some hex file sizes and not others. It would be very confusing.

Will check on this for you. Our IFU expert (Dat) will be back on Monday, him and his wife had a baby :slight_smile:

1 Like

Congrats to Dat!!! Something must be in the water at GHI!

Congrats, Dat!

At this rate, the new GHI building might need a daycare.

Congrats Dat!

Thanks all :)). I hope in the future, my baby will be also a programmer same as all of you here. :)))

@ Iggmoe: You are right, we will correct it in next.

Temporary solution:
if you can, how about if we write a small C# application to add 0xFF into end of that hex file? and remember correct its checksum too :)).

@ Dat - Congratulations to you and your family! I assume it is a boy. :wink:

@ Dad - Thanks for the tip on the workaround. If the new firmware will be released in 4 weeks or less, I think I can wait for the official fix. Out of curiosity, what kind of checksum is it? Simple additive checksum or CRC?

And no . . . that’s not a typo :slight_smile:

FYI the runtime crashes if you call SystemUpdate.Abort() twice in a row.

EXCEPTION 0x05:
cpsr=0x01000000
pc =0xa09c1cb8
lr =0x00000016
sp =0x100011a8
r00 =0xa09c1f28
r01 =0x00000000
r02 =0x00000001
r03 =0x00001000
r04 =0xa099e018
r05 =0x00000016
r06 =0xa09c1cac
r07 =0x05000000
r08 =0x00000000
r09 =0xa0024cd8
r10 =0x00000000
r11 =0x00000000
r12 =0xa099e018
EXCEPTION 0x05:
cpsr=0x01000000
pc =0xa09c1cb8
lr =0x00000016
sp =0x10001188
r00 =0xa09c1f28
r01 =0x00000000
r02 =0x00000001
r03 =0x00001000
r04 =0xa099e018
r05 =0x00000016
r06 =0xa09c1cac
r07 =0x05000000
r08 =0x00000000
r09 =0xa0024cd8
r10 =0x00000000
r11 =0x00000000
r12 =0xa099e018

@ Iggmoe -

They have been fixed.

cs = ~(dataCount + data[0] + data[1] +…data[dataCount -2]);

data[0,1,2,3]: address
data[dataCount -1] : where you put cs byte.

Or we can re-define the block size to make sure every block is bigger than 46 bytes