There’s some major changes in IFU implementation between 4.2 and 4.3 mainly about errors management.
In 4.2 I was using CanUpdate but in 4.3 this propertie is missing.
May we have more information on how to use the new classes? A tutorial with a complete example would be great. In the document section, the example is trivial and does not show how to manage errors.
This should help https://www.ghielectronics.com/docs/147/in-field-update
The new classes are a lot simpler than the old one so it should be easier and cleaner than what you had in 4.2.
I already read this but this example is poor.
What can we do if we receive an exception during initialisation? During Load (in this case the only thing to do is delete the file and restart the process), during flash? if flash fails does this mean the board won’t restart? in this case should we keep the last IFU files and reload and reflash?
IFU 4.3 may be simpler but I don’t think to have enough detail to know precisely what I am coding
Added comments to the code. Please take a look again.
My feeling is that this is the same as 4.2 except that CanUpdate property have been removed and that 3 new exceptions appear.
Again I still do not know how to manage these exceptions and what is the correct process in case of failure.
@ andre.m - exactly
@ leforban - no, not same. This feature was completely done new from scratch.
@ andre.m “restarting the process at the position where it fails…”
There’s no reason that restarting will change anything unless knowing why exceptions are thrown. Therefore I would expect a little bit more details about these exceptions.
"If you have a problem “during or after “InFieldUpdate.FlashAndReset()””, manually update the board.
I assume that if files are loaded properly and that the files are the good one, and no mistake on power line the process is 100% reliable. Manually update when the board is in the middle of nowhere is not an option.
In the previous version (4.2) canupdate was telling if something went wrong and if not the update was started and I only observed one mistake (that we can not still identify see my post on partial IFU that fails).
There is nothing to fail in the new way. Of course assuming the files you sent are valid. This is where you need to add some code to verify the new files, like adding crc.
Like I said before, it is extremely simple for a reason, to minimize or even eliminate any errors on our end. And it gives you the power to encrypt your new files, add crc or do whatever make sense for your product.
@ leforban - Exceptions are now thrown from each function where CanUpdate would have been false. If the function does not throw, it succeeded. I’ll look at the errors again to see if I can’t make them more clear.
I understand your point. But as you can imagine, this is not easy to know what could fire an exception. Let’s say exception for initialize…
My feeling is that an exception in this method can only be fired due to a lack of memory. Therefore what what are the options? dispose some elements? call GC? restart the board and the update?
This is these informations that we need to have a reliable products and this means we need a little bit more details (if non-exhaustive) about underlying reasons of such exceptions.
@ leforban - Most exceptions are because you provided an invalid parameter or you failed to call initialize first. Flash and Load can each throw a Flash and Load exception. Currently we do not expose why exactly those exceptions were thrown but it is something we would like to do. There are cases were those functions can also throw generic NETMF exceptions and we are also looking into improving those as well.
EMX is supposed to have tons of ram…
My products is alive all the time unless a power failure occurs and IFU can happens at any time not only at startup.
Correct but wet bit know how much ram you use. Simply, if you get an out off memory exception then you need to clear up some memory and try again or do it on lower up before you allocate large objects.
This is not a problem of rebooting the board, I can store files, restart the program and therefore infieldupdate.initialize will be perform at an early stage…
But what other reason could cause an exception in initialize… this is still mysterious and therefore no solution can be put in place to avoid that without more details…
@ leforban - Initialize can throw an ArgumentException when given an invalid type, InvalidOperationException when called more than once, OutOfMemoryException when the firmware can’t fit entirely in RAM, and another InvalidOperationException when there was an issue calculating the required amount of memory.
Good!
I don’t know how it can be possible to give an invalid type since it’s enumerated…
For the other exception it makes sense.
How the initialize can throw and OutOfmemory exception. You said that it can happen when the firmware can’t fit in RAM. But the firmware size is not known at this stage.
@ leforban - You can cast any integer value to an enum so we need to check that. Initialize allocates memory based on the types you pass to initialize and the board it is running on.
possible yes but it seems to me as useless as tricky in this context
@ leforban - Useless here, yes, but we still need to validate all parameters.