Where do I get the files from?
I assume that ER_DAT might be Firmware.hex, ER_FLASH might be Firmware2.hex, ER_CONFIG might be Config.hex and ManagedApp.hex is my application.
Is that assumption correct?
Then I come to my 2nd question: Where do I get ManagedApp.hex (or MyApp.hex) from? Do I create it with MFDeploy as if I would deploy it with MFDeploy or the FW Updater?
And 3rd question:
Do I need to have the …sig files in parallel? Well I assume no, because how could the SystemUpdate.Load() method know where the array is comming from.
This leads me to my final question:
Do you plan (or have) a method to manually check .hex files with theire .sig file?
Yes, you can use MFDeploy to extract your C# application in hex file. Note that MFDeploy work fine on EMX but on G120, you have to wait for a long time, maybe 10-20 mins.
Question 3:
No need sig file in case using IFU.
Importance:
Don’t disconnect power or reset while IFU is running.
It takes few minutes to finish, and running IFU on G120 is faster than EMX.
We will not support the core feature added in 4.2 as of now. It is new and no one used it yet. We can’t afford the risk involved in using it commercially.
We have enough headaches caused by switching the TCP/IP stacks to the new open source one
Thank you for the quick answer.
What do you mean by ‘you can use MFDeploy to extract’? Can I use something else?
What exactly takes 10-20 min. on the G120? Connect, download hex file? Will this be improoved in the future?
Not sure, It’s been a while since I read into this topic. But when Gus told me that GHI will not support this feature in the near future I stopped reading.
But I think it was some pdf document from netmf.codeplex.com.
btw. The GHI Interface is way simpler.
What exactly takes 10-20 min. => I meant when you hit OK button on “Create Application Deployment” window, MFDeploy looks like no responding, you have to wait for a long time.
Two more little questions:
If I download MyApp.hex from a EMX board via MFDeploy, can I use the same file for an G120 or do I need a seperate hex for every SOM?
The Docs say TinyBooter can not be updated by IFU. When is a update to TinyBooter usually necesarry?
I don’t see why.
The only reference that might be different is GHI.Premium.Hardware.EMX / .G120.
These only containes const for Pins. But I want to read the Pins from SD/file anyway, so I usually will not add these references.
Everything else should be the same. I already test the same code on EMX and G120, but currently I always deploy with VS.
OK, so the new IFU looks really straightforward, and this answers my question of how I can perform IFU over a serial port from a couple weeks back. As Reinhard asked, when is a TinyBooter update necessary?
The doc says that the GHI IFU(Premium 4.2.10) doesn’t allow to update TinyBooter while it was possible on the 4.1.8. Could it be a limitation in the future. Does GHI plan to update the tinybooter?
As we already have products in the field (a little bit everywhere in the world) how to update these devices from 4.1.8 to 4.2.10 without pb.
the 4.1.8 looks for some files that has been renamed…
CLR2.HEX is it now firmware2.hex ?
CLR.HEX is it now firmware.hex ?