Netmf 4.3 on STM32F4 Discovery?

Has anyone created a solution for the Discovery board in Netmf 4.3?

I am trying to compile my own firmware for this board with GCC. The only ready source code I could find for this board is Oberon’s Discovery4 solution based on netmf 4.2 with no support for the GCC toolchain, so I tried using FEZCerberus from the “NETMF 4.3 Community Ports” ( and only changed the frequency in Solutions\FEZCerberus\platform_selector.h, which should then run on the Discovery according to .

It builds without errors, but somehow TinyBooter does not work with MFDeploy from Netmf 4.3 SDK. It shows “Error: No response from device” on every attempt to erase or deploy.

Thank you for any help!

Isn’t the community firmware for Cerberus based on 4.3?

I think it is

I don’t have a link handy but a search ought to track it down.

As I wrote, this is what I was trying to use without success…

I think you will find a solution, if not an answer at:

I haven’t worked on this for a whole, but have always been able to get the Discovery to work with GCC since.


1 Like

Sorry missed the msg id:

1 Like

Thank you Stephen, your reports on that other thread look promising, I’m sure I will find out what the difference is here. Must be a stupid error. I’ll try again and report here…

Make sure you build TinyBooter and TinyCLR – flash TinyBooter using ST-Link, then flash TinyCLR using MFDeploy.

Full instructions:

While it doesn’t have the latest GHI modifications, the community ports collection I put together that you mentioned is definitely the easiest way to build firmware (since it has NETMF4.3 + GHI’s ports + patches to make it work on GCC + minor bugfixes). It’s the codebase I worked out of in school; it most certainly compiles without errors and works properly – as long as you have the environment setup properly.

First, grab a copy of it and put it in C:\MicroframeworkPK_4_3 (that’s the default directory; other directories may cause errors, as some of GHI’s code is hard-linked to that directory)

Then make sure you have this version of GCC-ARM:
(Yes, you need 4.6 – there have been complaints about 4.7. You can’t use Code Sourcery or any other toolchain. You must use this one)

I’d recommend installing it in C:\GCC_ARM_4_6. Don’t install it in a directory with spaces. NETMF PK can’t handle that (lame, I know).

Then go into Solutions/FEZCerberus/ and modify platform.h to change the crystal to 8 MHz.

Then, from powershell/cmd, call the GCC setenv.cmd with the path to your bin directory. cd to Solutions/FEZCerberus/ and run

msbuild /t:build /p:flavor=release;memory=flash

It should build BOTH TinyBooter and TinyCLR. You must build the release version, since the debug version is too big to fit in flash memory.

Once you build the two files, they’ll be in the buildoutput/thumb/gcc/ folder. Using ST-Link, connect to your Discovery board and upload TinyBooter.hex to the Discovery board. Reset the board, and ensure that it comes up as a USB device (obviously, you’ll have to plug a second cable into the USB micro connector on the board).

If it comes up as a USB device, open MFDeploy and deploy TinyCLR to it. Reboot the board again, and you should be good to go.

Unrelated, but related:
I honestly haven’t been working with NETMF much recently (it’s too slow for our current project, and the STM32F4 is too expensive), so I haven’t been updating the repo with the latest code changes from GHI. I hope that someone else can pick up the torch and get GHI’s firmware changes intelligent pushed into the repo – while advanced users might prefer the other ports collection floating around, I really believe that NETMF is overwhelming enough; there’s no reason to complicate things by forcing our new friends to download multiple packages to copy over things. I can’t think of a single other software project I’ve worked on where the repo can’t be compiled without copying it over some existing code.


thanks for the writeup. I repeated the steps, and it worked this time. Not sure what I did wrong the last time…

+1 for that. Why manually copy things over when we have git?

(I’ve never done any of this before)

I installed everything, change the external clock in the .h file to 8 MHz, and did the build.
I used ST-Link and flashed TinyBooter.hex (that was just built). Seemed to work.
The board shows up as the USB device and shows up in MFDeploy as Cerb-Family_Gadgeteer.

But now I don’t know how to use MFDeploy to, well, deploy TinyCLR.
I assumed I need to send the ER_CONFIG and ER_FLASH.
I selected ER_CONFIG and it shows up in the listbox, checked.
I then selected the ER_FLASH thinking it would fill in a second row, but it just replaced
the first one.

OK, so I put ER_CONFIG back and clicked the Deploy button.
It did some stuff, took a while “Checking Signature”. Then gave me a “No repsonse from device” error box.

Figured out you have to multi-select on the Open File dialog.
Managed to flash both pieces. That worked.
Reset the micro and restarted MFDeploy.
Ran the Ping and this time is says TinyCLR.
Device Capabilites reports this:

Connecting to Cerb-Family_Gadgeteer…Connected
Pinging… TinyCLR
HalSystemInfo.halVendorInfo: Copyright GHI Electronics, LLC
HalSystemInfo.oemCode: 255
HalSystemInfo.modelCode: 0
HalSystemInfo.skuCode: 65535
ClrInfo.clrVendorInfo: Copyright GHI Electronics, LLC
SolutionReleaseInfo.solutionVendorInfo: Copyright © GHI Electronics, LLC
SoftwareVersion.BuildDate: Jul 23 2013
SoftwareVersion.CompilerVersion: 4
FloatingPoint: True
SourceLevelDebugging: True
ThreadCreateEx: True
LCD.Width: 0
LCD.Height: 0
LCD.BitsPerPixel: 0
AppDomains: True
ExceptionFilters: True
IncrementalDeployment: True
SoftReboot: True
Profiling: False
ProfilingAllocations: False
ProfilingCalls: False
IsUnknown: False

Does this mean it worked?


I also see that message sometimes (not always - haven’t seen a pattern yet). But in the end, it always seems to work - the “no response” appears to occur only after successfully writing the data to flash.

My latest problem is Visual Studio can’t find Microsoft.SPOT.Hardware.STM32F4.
I’m looking for that to use Pins.GPIO_PIN_D_12.

And all my references, even when I add them by browsing to the build directory,

they all show up in Properties in Solution Explorer as being in
C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Assemblies\le\Microsoft.SPOT.Hardware.dll

Any ideas?

Yeah, I’m not sure you can have assemblies with the same name as “installed” base assemblies (in MF\4.3\Assemblies\etc).

For what it’s worth, you can just cast the pin number (which is 16*3 + 12 = 60) to a Cpu.Pin, i.e.,

new OutputPort((Cpu.Pin)60, ...)

I’m a total noob to this NETMF stuff.

I figured it out, or may have. I added As Link, this file to my project:


Didn’t try to run it yet.

STM32F4Discovery noob here…

As part of the 4.3 or even the 4.2 firmware setup instructions on the you need to install an unsigned driver. Is that the only way to get this working? I hate unsigned drivers or untrusted signed drivers. Anyone know how that driver is “made” and if there’s any chance to sign it?


Sure – you’re free to sign anything you’d like to. It doesn’t take any development work or source code or anything wacky. It’s really easy, actually. To sign a driver, you need to start by generating a catalog (.cat) file from the INF. In the WDK, there’s a utility called inf2cat. Just call it like this:

PS C:\> inf2cat /driver:<path-to-inf> /os:os1,os2,os3,etc

where /os specifies each OS to support (choices are 2000, XP_X86, Vista_X64, 7_X86, 8_X64, etc.)

Now, you need to obtain a certificate from a CA, and use it to sign the cat file. First, install the private/public key pair (usually stored in a .pfx file), and then use “signtool” to sign the catalog:

PS C:\> signtool sign /f C:\path-to-certificate-file.pfx the_pfx_password c:\

The reason the original driver isn’t signed is because CAs cost money ($500/year), so typically, only companies will sign code. You can obviously self-sign it using a randomly-generated certificate, but you won’t be able to distribute the driver to anyone else without having them install the certificate in their “Trusted Certificates” store on their computer. That’s why people bother with the CA route.

Obviously, if you change the VID/PID of the USB device to match GHI’s FEZ Cerberus VID/PID, you’ll be able to just use their (signed) USB driver without problems.