Mountaineer 4.3.1 Beta 3 - In-Field Updates "the Microsoft way"

This new beta release replaces Beta 2 and Beta 1. Besides a bug fix that affects Gadgeteer programs on Ethernet mainboards, it is a first in supporting Microsoft’s official [em]MFUpdate[/em] mechanism for firmware updates in the field - one of the gems hidden in NETMF until now!

[em]MFUpdate[/em] is a highly flexible and surprisingly light-weight framework for software updates in the field. It provides a simple API that gives you the tools to implement your own update strategy. For example, you could push a new firmware image over the Internet to a Mountaineer board using whatever protocol you like, use your own firmware encryption scheme if you like, etc. The update mechanism supports application updates, firmware updates, and combinations of both (important for example if you need to update some native code along with its C# interop code).

Here is the link to the new Beta release:

If you have already installed Beta 2, you only need to replace the [em]firmware[/em], using MFDeploy (replace the ER_FLASH.hex file containing the firmware image).

For more information on using [em]MFUpdate[/em], see the Web page here:

For a sample program that uses [em]MFUpdate[/em], see this Bitbucket repository:

For more background information, see this presentation:

Our special thanks go to Mark Munte, whose investigations made it possible for us to successfully integrate Microsoft’s update mechanism into [em]NETMF for STM32[/em]. Thanks Mark!


There is one caveat: Microsoft’s code contains a bug that leads to an update failure after about two dozen updates. Please add your vote for fixing the bug here on Codeplex:


As always well done

@ Cuno - Awesome!

Sorry if I missed something, but wasn’t this in GHI’s Premium offers already?..

GHI made their own mechanism, and did not follow the MFUpdate framework built into NETMF.

I wonder why…

When I asked, GHI said that the MFUpdate framework is way more complicated to implement/use then their own system.
I think that it also has something to do with binding customers to their product by making it more painful to switch to something else. And if someone uses all the nice features which are Premium lib only, then it’s really not that simple to switch to something else. That’s why I usually put an additional layer of abstraction around such features.

[quote=“Reinhard Ostermeier”]
MFUpdate framework is way more complicated to implement/use[/quote]
Yes and no. It was certainly not as well documented as we would have liked when we started looking at it, and not all elements have the same level of maturity. Thus our big kudos to Mark Munte, who did all the necessary research and paved the way. All in all, it turned out that MFUpdate is quite a small framework and gives a lot of flexibility.

I forgot to mention one thing: once we’ve reached the final release for the [em]Mountaineer[/em] firmware, we will publish the source code on our [em]NETMF for STM32[/em] Codeplex site, as we did with earlier releases of our port. This will include the MFUpdate stuff.

If someone wants to take a closer look before then, the original work of Mark Munte can be found in the [em]MFUpdate[/em] branch here


How could I use your firmware with Cerb40, for example? I’m interested in USB Host feature. Are there any how-to’s and code samples about porting the project from GHI’s firmware to Mountaineer’s?

@ toxsedyshev -
MFUpdate is so far only supported on Mountaineer firmware, so it’s not a matter of porting from GHI to Mountaineer, but the other way around.

USB Host has nothing to do with MFUpdate. There is limited USB Host support for STM32 in the non-open-source Mountaineer Prime firmware, but not in the standard firmware.

If your firmware supports all GHI’s firmware features why not to update our projects to get mfupdate feature? Or it doesn’t?

@ toxsedyshev -
Our firmware is strongly focused on the standard NETMF API, so we do not use GHI extensions in it.

Providing alternate firmware versions for GHI hardware would be possible, but it still would require work - in particular after the release, when all the tech support questions would inevitably land in our lap. It makes more sense for us to invest our highly limited time budget for NETMF in other areas.

Eventually we’ll publish our firmware as open source, so GHI can integrate it into their firmware if they like. As Mark Munte has published his contributions in the MFUpdate branch of NETMF for STM32 years ago, this has actually been possible for quite a while.

Can I install .NetMF 4.3 on my STM32F4Discovery? Where I can found instruction?

Now installed 4.2 and work excellent. But need OneWire, which realized only in 4.3.

No, onewire is in 4.2 as well. Not sure why you think that it’s only in 4.3 ?

Very strange, when I try to use a class in the project with onewire, I have permanent errors. In mountaineer firmware implemented this only in 4.3, that thought. Please, help me find reference to the class or use example on 4.2.

P.S. Sorry for my bad language, I am from Ukraine )

One wire on mountaineer was introduced in 4.3 and not available in 4.2
It was however avaialable in GHI products with version 4.2

Where I can found firmware from GHI for STM32F4Discovery?
Thanks in advance.

@ romanstorm -

In 4.2, GHI supports onewire for all products, include Cerberus which has STM32F4 same as STM32F4 Discovery board. (just discovery board may has more pins than Cerberus)

Show me your code and we can try to correct for you.

Cerberus 4.3 is not ready yet but it is on the way.

@ romanstorm - [quote]Where I can found firmware from GHI for STM32F4Discovery?[/quote]