Remote Deployment

I am about to build a couple more prototypes of a product that will use the Netduino. Deployment and debugging of the existing prototype have always been a problem with issues ranging from no deployment to VS crashes to BSOD to just plain instant PC reboots (Black Screen of Death). Now, I will need to find a way to update the Netduino code at a remote location without requiring the user to subject themselves to these problems and, hopefully, without them having to use VS at all. Is there a way to do that?

You mean like a custom PC application (on Windows?) to download new firmware from the internet and install into your product via USB connection?

You mean like a custom PC application (on Windows?) to download new firmware from the internet and install into your product via USB connection?

Well, that would be cool. I already have created a c# PC app that communicates via Bluetooth with COM2 on the board to receive and plot data from Netduino. I guess I could add a function to update the code over USB. Even if it was just able to use an emailed file that would be helpful. I'm guessing I could use MFDeploy although I've never used it for that purpose. I haven't had much luck with that connecting reliably either.

I am using 4.2 RC1. I am reluctant to do another update since the last update broke things that were working and set me back for a while. At the moment my code seems to be working well except for the depolyment/debug troubles.

Hi PhilG, You can use MFDeploy to deploy updates at client sites. You can also write your own simple app using the MFDeployEngine classes--and have your own custom UI. A quick note: the 4.2 RC4 firmware is much more refined than the 4.2 RC1 firmware. Chris

Hi PhilG,

You can use MFDeploy to deploy updates at client sites. You can also write your own simple app using the MFDeployEngine classes--and have your own custom UI.

A quick note: the 4.2 RC4 firmware is much more refined than the 4.2 RC1 firmware.

Chris

Actually, in general, you cannot do this, IE send a file to a customer and then have them update the firmware on an N+ board. It turns out there are just too many "gotcha's" for this to work in the general case. The reason I know: I sent several days trying to make this work with a customer with more than average level of tech experience. He finally had to give up and send the board back to me for updates.

Just think how many of us struggle to get our development environments working reliability. This is pretty much what you would be doing at the remote site: having your customer set up a development / deployment site.

Hi Robert, We have automated programming/test jigs (powered by a PC and a Netduino) which program and test each Netduino which comes off the line. But we do have computers already setup, etc. Perhaps the issues you're seeing in-field can be addressed in NETMF vNext. Could you please enumerate each of the issues/glitches and we can correlate them with bug reports on netmf.codeplex.com...or make sure that additional bug reports get filed? Chris

Hi Robert,

We have automated programming/test jigs (powered by a PC and a Netduino) which program and test each Netduino which comes off the line.

But we do have computers already setup, etc.

Perhaps the issues you're seeing in-field can be addressed in NETMF vNext. Could you please enumerate each of the issues/glitches and we can correlate them with bug reports on netmf.codeplex.com...or make sure that additional bug reports get filed?

Chris

I probably cannot enumerate all of them, but I can start with three of them which are "show stoppers" in my opinion.

One: This is apparently a known problem with no workaround. My customer's computer was a Windows XP machine, and MFdeploy will not run on XP apparently. Other customers of mine run Linux or MAC based machines, same issue. For me personally, MFdeploy runs on my Vista desktop, but there are many other machines with other OS's that I want/have as customers. I am not in a position to insist they have a certain OS before they can accept an update to my managed code.

-----

Problem two: There are times when a new TinyBootDecompresser.bin would need to be installed before the MFdeploy could be used. This happened going from 4.1 to 4.2 for example. My opinion is that my customers would not be able to successfully follow the steps needed to update the TinyBootDecompresser.bin.

-----

Problem three: MFdeploy is a "fussy" program. It sometimes works, but sometimes takes several attempts before it can load new code. Also it's more "developer friendly" than "customer friendly" and I doubt that my typical customer would be able to use it successfully without excessive hand-holding.


------

I personally think what is needed is a way to flash/boot from the SD card. That way new versions could be placed on the SD card, and upon a reboot would be installed and then run. The booter would have to be smart enough to use the existing flash unless there was an update. Either version control or some flag could control this. There could be a special directory "/boot" containing the code. Several versions could be stored there so the booter could "fall back" if a new version failed to run properly.