If we buy say 200 EMX modules and have them places on our PCB’s. what is the fastest way to upload our firmware to these boards and get them on burn in.
Thanks
I believe the general solution to this problem is a set of pogo-pins in a custom-built jig. Here is a Sparkfun tutorial giving all sorts of tips and photos to go along:
Thank you, i was more looking for what application would i be using to download the files to the board. I am sure i would not be using VS2010 for that.
Ah. I believe MFDeploy could be what you’re looking for. For 200 units you could probably make it work. For 2000 units, however, I’d probably look into something custom-made that would be a bit more automated. I’m sure the PC-device protocol is documented somewhere.
I usually flash 3 or 4 units at once. I deploy one unit with Visual Studio, then under MFDeploy create an application deployment. This will give you a hex file and a signature. You can then deploy the hex file to all your other boards using MFDeploy just like a GHI SDK update.
Since I do such small runs, mostly firmware updates on our office devices, this works for me. You can also use this HEX file for the built-in system update feature but that of course requires you to create the self-update application.
Thanks guys.
Hi,
it all depends on what you need to update in the pcb’s. Is there the latest version of .net and ghi already in there or not?
We supply pcb’s in batches of 100 now for a customer. We wrote a program for that. Which has the option to update .net and tiny booter first. After that it can update the main program. I bit like the emx updater from ghi.
But we also use the infield update option of ghi. This requires some additional steps in the loading process. Because you will first need to enable that option through a small .net micro program you upload and run first. Then you will need to deploy your infield updater code to the right part of the board memory and after that the main code to the right part of the board. That all takes a bit longer… (it isn’t quick at least 
) But that is all done through the mfDeploy API.
We want the self/auto update option for our customers. They can now just plugin a USB stick and the device will update itself, but i don’t know if you need that feature.
Regards,
Per
Just getting a general idea of what i am headed towards before i get to deep into this .netmf stuff.
With our current ARM7 product it takes the tech just 6-8 seconds to flash the board with JTAG.
Seems i will first have to make sure the firmware is latest and if its not, complete that. then upload my firmware. what what i have played with the Cobra doing this i could be looking at a 30 second process. @ 100 PCB’s * 30 seconds = 50 minutes. compared to 100 * 6 = 10 minutes.
YEA! will need that as well.
But do you load over 1MB worth of data? and loading to internal flash + external flash? 
I agree that production with NETMF will require a bit more time to load the device but if you want to compare then at least have the same file size.
true, typically they are just under 512k in flash.
Just curious about this, though my intention is to use the EMX module at this time. I have not looked into this yet it just occurred to me now. Since the EMX module has JTAG pins on it, would it be faster to flash it that way instead of using the USB ?
JTAG is not available on EMX fro now
But i see them on the pin out description. J7-J12.
[url]http://www.ghielectronics.com/downloads/EMX/EMX_Broch_Pinout.pdf[/url]
Yes the pins are there but support is not available at this time.
Even 30 sec you won’t even make, it takes way longer if you need to do everything. If you want to do the entire package for the first time then you will need to update (if the latest versions aren’t in your device yet). First update tiny booter, then update the 3 clr files, then deploy a program that enables the update funcionality. The memory will then be splitted into 2 sections (which takes some time). And then you will need to deploy the update section program and then the main program. Between deploys you will need to wait for the processor to reboot and start the program that is in there.
This can all be done with the mfdeploy api, but it takes minutes overhere to do an entire set for a board that needs total updating. At least overhere it does… Looking at our code i don’t see how we can speed this up. The main time is going into the waiting for the device to be ready between deploys i think.If you don’t need to updating facilities it can go much faster because that will cut a number of steps in the process.
I think we are looking at around 2 to 3 minutes per device at this moment. So we have rigged up 5 pc’s to do 5 boards at once.
Regards,
Per
Hmmm… Strange, I would have thought that the whole process would be better / faster. If a company were to go into mass production how in the world would they pull that off.
My boss is not going to like this tid bit one bit.
haha yes that is our issue to.But since we are going to deliver now in batches of 100 pieces it is doable for us, At this moment the self updating part is the one that takes up most of the time (and the waiting between rebooting ofcourse). But you can see the time it takes to just update the firmware file through the normal mfdeploy program.
For previous projects we used the jtag interface of our designs also (where all projects with atmel processors). But like Gus said, you are transferring a lot more data now to internal and external memory.
If we are quickly we can upgrade and re connect a device in 4 minutes. So that is 5 devices in roughly 5 minutes. Times 15 (which you don’t get ofcourse) is around 80 per hour. But you won’t reach that. But still, you can get quite some devices made in a day in this way.
Our customer doesn’t sell that much units per day at least 
I don’t know the sales potential of your boss his product though 
Regards,
Per
Wow, very interesting. I guess i made to many assumptions on .net when i started. I got so over excited seeing all it could do i just assumed to much and jumped in with both feet.
We have some customers that order 500 units at a pop. if i use a time of 5 minutes per unit as an example it would take a guy a little over 41 hours to do this. That is paying a guy 5.1, 8 hour days just to program boards.
Let me ask this then, is this just specific to GHI boards, or just .netmf in general ?
I currently use NetBUrner Modules for my Ethernet devices. My current application is 490k out of the 512k available. It only takes 6 seconds to download the firmware via Ethernet to the board and its ready to go. Even if i were to double or triple that time to mimic a 1meg download i have not even hit 30 seconds yet. So where is this bottleneck at outside of the rebooting time ?
You assuming one person can only do one board at a time, if one board takes five minutes they would have about 4 min free after accounting for swapping boards. If you set up five PCs set up for programming (or one PC set up with custom software to do the programming) as Per said then you have five times the programming rate and still only one operator. I’m guessing that if you had a really large production of products then it might be better to talk directly to GHI about the alternatives.
True, bit is this a .netmf issue or a GHI issue why its so slow or both?
i cant help but to imagine if one were to make something like the iPhone built on .netmf where they sell millions. Cant imagine how they would pull that off.
Millions? 
Oh yes GHI will do all the programming for you, free of charge
No seriously, if you need programming service then GHI can assist for small fee. You will need to call GHI directly about this