@ Gus, thanks for the heads up. But that would require us shipping the product to you then back then we would have to burn in and ship out to customer. I have to say i shocked that flashing a device is this time consuming. Feels like the old days when i would have to take an ole EEprom to the UV eraser.
Hey Gus, just thought of this, how do you guys do it there ?
Say someone ordered 200 EMX boards. How do you put the firmware on it and do you guys do a burn in or just a quick test.
You do not ship us your product but when you order EMX you give us the files to program them for you.
That is the simplest solution. That is the way we will go then.
Let me ask this, lets say there are a few hundred out in the field. and some months later we have a software tweak. Also lets say that in order for this new tweak to work there is also a new rev for the GHI NETMF SDK. that must be installed first.
Can this whole update procedure be done via the customer placing a USB stick into the device ?
I.E. it will update the device to the latest GHI SDK firmware, then after that is successful update our software into the device ?
For in-field you use in-field update feature, can be automated and will only take 2 seconds!
Yes the infield update functions works great! So after we have programmed our boards for the first time upgrading is so easie. The user just plugs in a usb stick and there it goes (it does some internal checking in our code ofcourse to look at versions etc). But it works like a charm. I haven’t tried it over a network at this moment (so we can do remote updating). We always keep a backup of the previous software version on the sd card, just in case.
Did some searching on IFU. So am i to understand that this is the writeup for it ?
IMHO, there should be a sticky for this IFU. when you do a search for it, there are quite a few people with issues about this.
Let me ask GHI this, then why from the factory when you buy a EMX module you guys dont load up this application into the units ? Seems to me that if i were to order alot of them i would just buy them as off the shelf items when they are installed onto my boards i could just have the tech stick the SD or USB pen drive into the deice and have it update itself in a few seconds. No need to pay GHI an extra fee to do something. Also by installing this boatload app would not interfere with other people that say had a kit. Because as soon as they plugged it into VS and downloaded their app it would overwrite it. This way the EMX module would be more accommodating to everyone.
IFU is very flexible, you may want to update from USB stock or from network. Maybe load an encrypted software! It is up to you and so the application to use IFU should be made by you.
You see a lot of questions about it because it is not simple to understand. It is not very easy to get a device to update itself 
what about the question i asked ?
is that link the main source for learning IFU ?
Before making sure we want to start using .netmf i want to make sure that this is something that we can implement easily. I need to be able at the very least have the user install a USB stick into the device to update it. The preferred method would be via network.
Well… It is quite easy to use. But before we understood how to enable it and do the deploying to the different memory parts… that took some time and head aches…
i should make some time free to update the wiki about it maybee…
Yes that is the right link for IFU
@ GUS, Thank you.
@ Per Cramer, It would be nice to have a clear article on the whole subject.
Though i would have thought GHI would have done it. To me something like this is one of the most important features a device should have. I look at all networking devices this way. If you got a network jack and you cannot update yourself… whats the point of being on a network.
Old topic, but I am still interested.
We have a prototype with the EMX module that should fortunately become a product ( we plan to do more than 100 of them each 6 months)
We also use the infield update option of ghi, wich is great but made the flash procedure long and tricky…
So the fastest way to flash production units interests us and we have several questions :
1)Deployment seems to be faster with Visual 2010 than with MFDeploy (20 seconds vs 50 seconds) . Any clue about that? Do you think that it is possible to use command line VS2010 to automatize flashing of production units? VS2010 doesn’t seem to be command-line friendly, but maybe I am not looking at the good place…
2)Just in case, is there any support of JTAG, since the beginning of this thread?
- is there a way to split flash, flash bootloader and flash API with one single operator action? For now the flash procedure implies :
- DeployProductionApp (with MFDeploy), for enabling booltoader (i.e. splitting flash)
-after that, wait that this application restarts automatically, detects that the split has been done, and so restarts in bootloader mode
-wait that the application has restarted in bootloader mode
-Deploy managed bootloader (with MFDeploy, again), wich will detect the “nominal.hex” binary file (in our case on USB stick) and auto-flash it
-wait the last restart and check that application is correctly running
It makes a lot of deploments and reboots, and a long time ??? (about 5 minutes with our application without flashing the NETMF firmware)… And the operator has to stay during the process , since it has to deploy first the ProductionApp, then the managed bootloader during the process.
What I will try to do is to write a script that uses MFDeploy in command line mode, detects when the EMX board is plugged to the PC, (with ping) then auto-deploy the ProductionApp…and then (after some condition or timeout that indicates that board has rebooted in bootloader mode) auto-deploy managed bootloader … So the operator coul just plug the USB debug link to the PC, and never watch the PC. I guess this script should manage two ore more boards at same time on a single PC…
I would be interested to share your feelings about that and if you have a better idea 8)
Thanks for your support…
Regards,
IFU was completely redone in 4.2 and there is no boot flash and app flash anymore.
If you are buying hundreds of modules then the best way would be to talk to your team directly and we can together find the best approach. Maybe a custom version of FEZ Config…or a tool update.
However, using MFDeploy DLL as you suggested will be the best way to handle this I think.
Thank you Gus for quick answer.
As you guess, we work with NETMF4.1 and we validate all our API with it.
I will consider moving the application to NETM4.2, and try to figure out if this new IFU makes enough time-saving at production time to justify re-implementing and re-validating everything.
I will bench this exemple with something representative in size as soon as I can ( not in the next 3 days)
http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation%20v4.2/Premium/html/da86348a-19c7-08a9-a6b9-78084dffc903.htm
The In-field update feature of NETMF 4.2 seems definitively the good option. (simple and fast comparatively to NETMF 4.1 ). So I will make the effort to move my API from 4.1 to 4.2.
What we plan to do to save time during production is check that the firmware is 4.2 (thanks to custom API based on MFDeploy DLL) and update the firmware ONLY if version is not the one that is expected, then deploy our API.
The question is : If we order 200+ EMX modules from GHI (and not from local vendor) in a few weeks, what firmware will be built-in? 4.2, or you have some devices that are on 4.1?
It is going to be 4.2 for sure but what version of 4.2 is not gursnteed. But you can contact our sales and for a small fee we can load whatever you want before we ship.
We use a BATCH file do make production deployment of the firmware and application.
The file calls a TeraTem scipt to update the tinybooter before deployment.
Make sure you have signed the application file so there will be a “Application.sig” file next to the application.
You need to put you module in loader mode with hardware pins.
This production deployment takes about a minute on G120.
Deploy.bat
call "C:\v4.2.11.0\Update G120_TinyBooter.ttl"
TIMEOUT /T 5
start /B /W "" "C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Tools\MFDeploy.exe" erase /i:USB:G120_G120
start /B /W "" "C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.2\Tools\MFDeploy.exe" "DEPLOY:C:\v4.2.11.0\Config.hex;C:\v4.2.11.0\Firmware.hex;C:\v4.2.11.0\Firmware2.hex;C:\v4.2.11.0\Application.HEX" /i:USB:G120_G120
PAUSE
Update G120_TinyBooter.ttl
; Macro for Tera Term
; Update G120_TinyBooter
timeout = 30
:start
connect '/C=80'
flushrecv
send 'E'
wait 'Erase all memory! Are you sure?'
send 'Y'
wait 'Done.'
send 'X'
wait 'C'
if result=0 messagebox 'ERROR' 'Result' goto end
if result=2 messagebox 'ERROR' 'Result' goto end
xmodemsend 'C:\v4.2.11.0\G120_TinyBooter.GHI' 3
closett
if result=0 messagebox 'ERROR' 'Result'
if result=2 messagebox 'ERROR' 'Result'
:end
end
@ Honken : Thank you for that, I have successfully tried something approching and will now try to do two scripts waiting a connection in an infinite loop, and deploying when board is plugged: The idea is to allow one single PC to autoflash two boards in the same time, without even using the keyboard… basically in your script the interface " /i:USB:G120_G120" could be changed to “/i:USB:G120_G120 (2)” to make a second script…
But is it really necessary to update tinybooter?
@ Gus : [quote]It is going to be 4.2 for sure but what version of 4.2 is not gursnteed[/quote]
->Thank you for that information, I was not aware of that, I was thinking that “4.2” was a fixed version, and that only the one available from .NET Micro Framework – GHI Electronics was spread to the world.
What are the different 4.2.xx versions ? are the log changes available? But reflashing the proper firmware version in our factory seems by far safer.