Cant flash cerb40ii with 4.2 for DS2010 or deploy or run code

OK I’m a little embarrassed to reach out so soon, but since I’ve flashed netmf many times on other vendors’ boards, I don’t think I am completely in the dark on the process. Yet I am unable to flash my new cerb40ii, nor able to deploy and run built code.

OK, I will write a short story, and then a long story. Short story:

  • flashed firmware for netmf 4.2 with some difficulty, and still cannot deploy and run with devstudio
  • flashing difficulty with mfdeploy, complaining about signature of firmware.hex
  • circumvented mfdeploy my making a dfu and flashing with STM tools
  • firmware behaves little oddly from a mfdeploy ‘ping’ standpoint, and others
  • and either way cannot connect with debugger in DS2010 to deploy and run

Long Story:


  • cerb40II
  • Win7x64
  • DS2010(ultimate if it matters)
  • installed ‘GHI NETMF v4.2 and .NET Gadgeteer Package (04-30-2013).zip’
  • unzipped
  • ran ‘Setup.exe’
  • proceeded through it all
  • because I’m weird, I also sucked off a DFU from the board of its factory state so I could revirginate it if I needed. And needed I did!

OK, it appeared the boards ship with no CLR installed, only a TinyBooter. So, I researched and did as suggested by using MFDeploy (yes, I could ping the board and see ‘TinyBooter’), and selected files:

  • in dir:
    “C:\Program Files (x86)\GHI Electronics\GHI OSHW NETMF v4.2 SDK\FEZ Cerb Family\Firmware\Non Ethernet”
  • Config.hex
  • Firmware.hex
    This process failed with a ‘signature check’ error. Hmm. OK, so I revirginated my board by erasing and using the DFU I created earlier and validated and tried again, a little differently this time:
  • I deployed just Config.hex. This worked, and passed the signature check.
  • I deployed just Firmware.hex. This proceeded until ‘Deployment Status, Checking Signature…’ reached 100% and boy howdy it did stay there so long that I thought it was hung (like 15 min or so) so I tapped ‘cancel’. Who needs signatures anyway?
    But I did cycle power on the board, and tried to ping. After an unusually long delay, I got:
    Pinging… I Electronics, LLCTinyCLR
    I Electronics, LLC
    Hmm, looks kooky! I try ‘Target, Device Capabilities…’ and after another long delay get:
    I Electronics, LLCHalSystemInfo.halVersion:
    HalSystemInfo.oemCode: 0
    HalSystemInfo.modelCode: 0
    HalSystemInfo.skuCode: 0
    SolutionReleaseInfo.solutionVendorInfo: Copyright © GHI Electronics, LLC
    SoftwareVersion.BuildDate: Apr 25 2013
    SoftwareVersion.CompilerVersion: 410713
    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
    OK, the first line looks bad, but the rest seems sane. The very long delay before response is disturbing.

I try making a project in DS2010. I use ‘New Project, C#, Gadgeteer, NetMF 4.2’, and select a project name and do nothing other than change the text in the Debug.Print() to utterly clear that it is my code that is running. Compile, run…

No deployment. Eventually I get some error spew:
------ Deploy started: Project: CerbyNumNum, Configuration: Debug Any CPU ------
An error has occurred: please check your hardware.
Request failed
Source: Microsoft.SPOT.Debugger
Stack :
at Microsoft.SPOT.Debugger.Engine.Request.Wait() in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 761
at Microsoft.SPOT.Debugger.Engine.SyncRequest(OutgoingMessage msg, Int32 retries, Int32 timeout) in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 1963
at Microsoft.SPOT.Debugger.Engine.ResolveAllAssemblies() in c:\depot\current\CLIENT_V4_2\Framework\Debugger\Engine.cs:line 2941
at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.Deploy() in c:\depot\current\CLIENT_V4_2\Framework\CorDebug\VsProjectFlavorCfg.cs:line 869
at Microsoft.SPOT.Debugger.VsProjectFlavorCfg.<Microsoft.VisualStudio.Shell.Interop.IVsDeployableProjectCfg.StartDeploy>b__0() in c:\depot\current\CLIENT_V4_2\Framework\CorDebug\VsProjectFlavorCfg.cs:line 634
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========

I think the board is perfectly fine, but something is awry with either the firmware I am flashing, or maybe the process by which I flash, etc.

And so my story ends: a sad and sorrowful tale, alas; of a fateful fail of a fraughtful flash.

Any advice appreciated!

@ ziggurat29 - Welcome to the community and sorry to see you are having problems.
Have a look at this guide and follow it to the letter. Especially the bit about create from map and erase etc as thats really important for the cerb. Keep us posted

@ hughb - thanks, but I have erased like a madman. I wonder where I can find older builds of the firmware to try? This one appears to have been made a few weeks ago.

That’s very odd. I’d suspect the file you were trying to flash might be corrupt (odd as that sounds), as I’ve never seen MFDeploy complain about a bad signature. Try re-downloading the file. If that doesn’t work, we’ll have a look at your hardware.

There were a few of us getting that a number of SDK’s ago, i even had it myself…
And no, i dont know what the answer was - just magically disappeared…

@ ziggurat29 - see if this helps

@ ziggurat29

How are you connecting the board to power? Are you using a straight USB power from the PC or from a Powered USB hub?

@ aron: usb power from computer. bear in mind I have flashed netduinos a bookoodle of times no prob, and if anything they have a little more power load (with an ethernet chip onboard)
@ justin: I’m assuming by that link you mean ‘try using portbooter instead’ I’ll try, but I can’t just this second, it’ll be a few hours before I get near the unit.
@ jay: i’d love to download firmware (and previous builds of it) but I am embarassed to say I cannot find where firmware is located. can you help a dummy out with a link?

@ ziggurat29

Please try with a powered USB hub if possible.

@ Aron: alas, powered hub did not ameliorate the issue.

@ Justin: upon closer reading of the article, it appears in their case it is about deploying an app rather than the firmware, but I don’t know if that really matters much since app deployment hex files are simple srec files like your firmware distro anyway. But no dice. In fact, I get something completely different
Deploy with PortBooter Command
Error: Object reference not set to an instance of an object.
Deploy with PortBooter Complete
so that took all the joy out of it.

I’d really like to try an earlier firmware build if someone can point me to where they are stored. I feel very confident that the flashing operation itself is occurring correctly because:

  • ‘verify’ say so
  • if I extract back out the flash image with the dfu tools, and trim it, I can diff it against the original successfully.