Make sure you build TinyBooter and TinyCLR – flash TinyBooter using ST-Link, then flash TinyCLR using MFDeploy.
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.