Spider II behaving odd

I’ve just connected a new Spider II to power (socket 1) and my T43 display and powered it up via USB to my desktop.

The display comes on all white with no text/messages, trying to deploy a trivial new app fails yet MFDeploy sees Tiny CLR (pings work).

The VS template only offers “Spider” as a mainboard not Spider II, is that a problem?

When power is applied both the red and green LEDs come on and stay on.

Is this normal and I’m doing something wrong, or is this suspicious?

I have a second Spider II but won’t try that until I get some feedback from others here.

The Device capabilities seen in MFDeploy are:

Pinging… 6216 bytes available
Pinging… TinyCLR
HalSystemInfo.halVendorInfo: Microsoft Copyright © Microsoft Corporation. All rig
HalSystemInfo.oemCode: 255
HalSystemInfo.modelCode: 0
HalSystemInfo.skuCode: 65535
ClrInfo.clrVendorInfo: Microsoft Copyright © Microsoft Corporation. All rig
SolutionReleaseInfo.solutionVendorInfo: Copyright © GHI Electronics, LLC
SoftwareVersion.BuildDate: Jun 26 2015
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


PS, when the VS deploy fails, the message seen (in VS) is: Device not found or cannot be opened - USB:Gadgeteer.

More info - somehow, got deploy to start but debugging fails:

Found debugger!

Create TS.

Loading start at a0e6938c, end a0e98820

Assembly: mscorlib ( Assembly: Microsoft.SPOT.Native ( Assembly: Microsoft.SPOT.Security.PKCS11 (4.3
.1.0) Assembly: System.Security ( Assembly: Microsoft.SPOT.Hardware (
Assembly: Microsoft.SPOT.Graphics ( Assembly: Microsoft.SPOT.TinyCore (
Assembly: Microsoft.SPOT.IO ( Assembly: System.IO ( Assembly: Microsoft.SPOT.Hardware.Usb (
Assembly: Microsoft.SPOT.Hardware.SerialPort ( Assembly: Microsoft.SPOT.Touch (
Assembly: Microsoft.SPOT.Ink ( Assembly: Microsoft.SPOT.Hardware.PWM (
Loading Deployment Assemblies.

Attaching deployed file.

Assembly: Gadgeteer ( Attaching deployed file.

Assembly: GHI.Hardware ( ***********************************************************************

  •                                                                 *
  • ERROR!!! Firmware version does not match managed code version!!! *

  •                                                                 *
  •                                                                 *
  • Invalid native checksum: GHI.Hardware 0xEB638545!=0x9E02C59C *

  •                                                                 *


Link failure: some assembly references cannot be resolved!!

Assembly: Gadgeteer ( needs assembly ‘Microsoft.SPOT.Net’ (

Error: a3000000

Waiting for debug commands…

The program ‘[3] Micro Framework application: Managed’ has exited with code 0 (0x0).


Microsoft.SPOT.Net is referenced in the project and is version
No assembly named GHI.Hardware is (explicitly) referenced by the project incidentally.

Hmm - seems to be a duplicate of this:


But I have no idea what’s wrong here, it has 4.3 loaded and I’m deploying 4.3 code…

I ran FEZ Config - check for device update and get this:

Loader (TinyBooter) version information: on this computer. on this device.

The Loader (TinyBooter) not up to date. <<<

Firmware (TinyCLR) version information: on this computer. on this device.

The Firmware (TinyCLR) is not up to date. <<<
Please wait for the device to reboot… Done.

I’m puzzled, must I “downgrade” the device?

Will resolving this impact already working code on a Raptor system?

@ KorporalKernel - If you look at the first set of output you will see that the display parameters have not been set. You can set the parameters by building a program with a display module. After that, when you boot, you will see the initial screen.

Pretty explicit. You need to have your SDK install and the firmware matching as well. If you want to update the SDK you have installed, then you may not need the firmware update, but the install of the firmware and the SDK libraries must be a perfect match for reliable operation

It may be explicit but its not informative. What exactly must be done? My Raptor deploys fine with the current SDK, and I downloaded the SDK from here just a week ago. If I do find/download a newer SDK, will the raptor also then begin to fail when I deploy to it?

Overall Im confused by this.

SDK versions do change - not overly often, but they do. You must have the 2014 R5 release installed ? The 2015 R1 release has happened only in the last week - so very unfortunate timing.

Think about this in simple terms (that is probably completely wrong under the covers, but I think its a good enough analogy). The firmware on a device lays out the netmf core components in a particular way. Your SDK has to know where each part of the code has to be in order to call it correctly. So when you generate code using a different “map” because the SDK and firmware are out of sync, your calls may fail.

So the easiest way you can move forward is to use Fez Config and deploy the firmware that your SDK contains (and is “mapped” against) onto your device. Yes, that may be a downgrade - but it’s aligning the two pieces you need to have aligned.

Another way is to apply the latest SDK, if you’re not already using it - and then, you’ll need to update your Raptor device with the matching firmware (and there’s some work to do to clean up your existing project code but that’s a story for another time). Basically, what ever SDK you have installed, the devices must match that version, and the references in an existing project must match that version. And if you have multiple PCs that you’re using to develop software on, you should work to keep them using the same SDK.

My #1 rule when I pick up one of my netmf boards is to run Fez Config across it, and deploy the (then current) SDK’s matching firmware, as I can never be sure I updated the board since the last SDK was released. If you’re doing commercial development, then my #2 rule would be to make sure you are including the specific SDKs you’re using as your baseline in your source/media control library so that you can ensure you have access to everything you need if you needed to have someone else develop against that code. Since I’m just a backyard maker, I just take whatever is current, and update my firmware as needed.

Is that helpful?

@ Brett - Hi Brett, yes that was a helpful guide. I’m new to all thos NMF stuff so may ask naive questions, but I need clarity in order to move forward so thanks.

Here are some more pointed questions then:

  1. There seems to be two chunks of code involved here - TinyBooter and TinyCLR (aka firmware) ?
  2. Each of these is independently versioned?
  3. The SDK installed on PC has copies of these ? i.e. each chunk exists in two places - the board and the dev system?
  4. TinyBooter on board and PC must be the same version, same for TinyCLR.
  5. I can upgrade PC’s SDK or downgrade the board - either option is safe (assuming no dependencies on new feature) and wont “break” my board?
  6. FEZ Config updates the board’s TinyBooter and/or TinyCLR to match whatever is on PC’s SDK, this may be upgrade or downgrade - all depends on what SDK is on PC.
  7. The SDK is a GHI component, not provided by MS and quite independent of the .Net MF Framework version?


It seems I can download the latest SDK (yes I see it changed very recently) but once I do that, must I then run FEZ Config against each board to get them updated - is that as simple as running FEZ Config and basically clicking “Firmware Updater”?

Once that’s done, in existing projects, are there references that must be removed/added again if so what refs are these (I assume there GHI specific assemblies)?

Many thanks to ya’ll and I appreciate the help.


Just for my own sake, I’m summarizing the version for both boards here:

Spider II

Loader (TinyBooter) version information: on this computer. on this device.

Firmware (TinyCLR) version information: on this computer. on this device.


Loader (TinyBooter) version information: on this computer. on this device.

Firmware (TinyCLR) version information: on this computer. on this device.

Latest SDK on GHI website:

Loader (TinyBooter) version information:

Firmware (TinyCLR) version information:

So this tells me that the Spider II a G120, has some pre-release version of TinyCLR ( as opposed to

I guess I just need to download/install latest SDK then run FEZ Config on each board and use “Firmware Updater” is that the case?

Also when I download and run the installer for the new SDK does it automatically uninstall the previous version? are there any additional steps or checks one must do?


Because your firmware is old, you probably need to update both TinyBooter and Firmware. For FEZ Spider (EMX) and FEZ Spider II (G120, G120E), you have to go “FEZ Config → Advanced → Loader Update”. Follow those instructions.
For FEZ Raptor (G400)
Follow this link for update TinyBooter:
After that you can use the “Firmware Update” button in FEZ Config to update G400 Firmware.

[quote]Also when I download and run the installer for the new SDK does it automatically uninstall the previous version?

We recommend that you should uninstall first, although it isn’t needed in almost PC.

No, unless you want to change them.

@ Dat - Thanks for that info but menacingly the document for the G400 has “Obsolete” stamped all over it, doing something as critical as this is surely covered by a current document?

The bottom line here is this

In order to play around coding on the Spider II I need to either downgrade it to the same Loader/Firmware that’s already on my machine or install the latest SDK and upgrade the Spider II to the new Loader/Firmware.

If I do follow the upgrade path, then I’ll have to also upgrade the Raptor because that will become out of date as soon as I install the new SDK.

So - for now at least - can I downgrade the Loader on the Spider II and then downgrade the Firmware on the Spider II so that my Spider II AND my Raptor are using the older SDK.

That is - to be very clear - can I do this without risk:

  1. Downgrade the Loader on the Spider II from to
  2. Downgrade the Firmware on the Spider II from to

That will make the Spider II compatible with my current SDK and since the SDK doesn’t change my Raptor wont need updating either…


(My worry is that downgrading the Loader on the Spider II might somehow make it incompatible with the more up to date Firmware already present on that Spider II).

Spider II (G120E) is new product so I don’t think SDK support this product. Even if it does support, it was in beta or initialize state. Using latest SDK is the best for your project.

Don’t worry about upgrade to new SKD, we can help you.
Also, support on latest SDK is easier than an old SDK, which was release few months or one year ago.

All you need to do after updated latest SDK is, go to your project, update all references GHI.xxxx.dll.
All functions with syntax, params in those dll should be same, even if they are different, easy to change.