11 replies to this topic

[Charles]

I would like to propose a new Netduino shield design - The firmware upgrade shield. Picture this... A shield with a 512k flash chip on board and the Netduino Plus with a modification to the boot loader to look for this chip. Upon boot, if the flash upgrade chip contains firmware that is newer than that in the on-chip flash, it upgrades the on-chip flash and reboots! Then all that would be necessary would be to create a small class to allow the firmware upgrade flash chip to be loaded with an arbitrary file and voila! A Netduino Plus that can be upgraded remotely! Alternatively, I imagine an appropriately-sized file could be reserved on an SD card, but this sounds to me like it would require more complex boot loader coding. Any thoughts??

[Flores]

You don't state this directly.. but this would allow upgrades by network, right?

[Charles]

By network, or any other data path over which the firmware could be passed and then stored on the NVRAM.

[CW2]

By network, or any other data path over which the firmware could be passed and then stored on the NVRAM.

There is "Remote firmware update middleware" feature in the official .NET Micro Framework roadmap planned (resp. committed) for the next release, and "Most likely an HTTP-based implementation will be provided as well as a sample...".

[Fred]

What I think would be far more useful would be the ability to update your own code over ethernet rather than the firmware. Firmware updates aren't that frequent, and if there's a problem your device is probably not in use. Bug fixes and updates to my own code in my permanently installed home automation application however - fairly likely.

[Chris Walker]

Fred, You could also, in theory, store your objects on an SD card. And then use app domains to load/unload them on the fly. We'll probably put a tutorial on this together in the future... Chris

[Charles]

What I think would be far more useful would be the ability to update your own code over ethernet rather than the firmware. Firmware updates aren't that frequent, and if there's a problem your device is probably not in use.

Bug fixes and updates to my own code in my permanently installed home automation application however - fairly likely.

It's all stored in the flash, be it our own app or the .NET firmware. The idea was to have a prebaked flash upgrade package that contains the firmware and our own app ready to go that could simply be copied to the chip's internal flash by the boot loader upon discovery.

Alternatively, I don't see any reason why an app couldn't be loaded on its own in the same manor, this would just require the boot loader to be able to recognize the difference and load the app at the appropriate address.

[Charles]

Any news on something like this, even if it is just for our managed code?

[Chris Walker]

Any news on something like this, even if it is just for our managed code?

Hi Charles,

Were you proposing building something like this? Asking to start a community project to build one? Asking for us to build one? Etc.

From your initial post, I assumed that you were thinking of building such a shield...

Chris

[Charles]

Building it would be fairly straight forward... However, hacking the boot loader to support it is a whole different story. It was just an idea... Since the N+ is network enabled, it seems like it would be really cool to be able to load code onto it over the network. This was just a suggestion on how that could be done. While I have extensive knowledge of IP layers 1 to 4, I have nowhere near the knowledge or experience necessary to alter the boot loader in this way. I was looking to the community to implement this if there was enough interest. According to this page: http://www.tinyclr.com/compare/ The entire FEZ series supports in-field updates. I would like to see this functionality for the N+. Does that mean that it would be technically possible to do this without the external storage?

[Chris Walker]

Does that mean that it would be technically possible to do this without the external storage?

Yes. You could use appdomains to do this on the fly through 100% managed code, or could build a feature into the Netduino firmware which would download and replace the application on the fly.

[Theoretically, you could also send the Netduino bootloader and/or firmware over the network, save it to an SD card and then read it back and reflash. Lots of possibilities.]

There's some work being done to support this with .NET Micro Framework 4.2. We don't want to duplicate that, but perhaps we can get an early cut of it ported over... It's very early right now.

Chris

[Charles]

Thanks! I'm a little irritated that it took Microsoft 4.2 versions to realize that this would be useful enough to implement though...