Microsoft.SPOT.Net is referenced in the project and is version 4.3.1.0
No assembly named GHI.Hardware is (explicitly) referenced by the project incidentally.
@ 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?
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.
@ 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:
There seems to be two chunks of code involved here - TinyBooter and TinyCLR (aka firmware) ?
Each of these is independently versioned?
The SDK installed on PC has copies of these ? i.e. each chunk exists in two places - the board and the dev system?
TinyBooter on board and PC must be the same version, same for TinyCLR.
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?
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.
The SDK is a GHI component, not provided by MS and quite independent of the .Net MF Framework version?
Finally:
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)?
Just for my own sake, I’m summarizing the version for both boards here:
Spider II
Loader (TinyBooter) version information:
4.3.4.0 on this computer.
4.3.7.7 on this device.
Firmware (TinyCLR) version information:
4.3.6.0 on this computer.
4.3.7.9 on this device.
Raptor
Loader (TinyBooter) version information:
4.3.6.0 on this computer.
4.3.6.0 on this device.
Firmware (TinyCLR) version information:
4.3.6.0 on this computer.
4.3.6.0 on this device.
Latest SDK on GHI website:
Loader (TinyBooter) version information:
4.3.7.10
Firmware (TinyCLR) version information:
4.3.7.10
So this tells me that the Spider II a G120, has some pre-release version of TinyCLR (4.3.7.9 as opposed to 4.3.7.10).
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: https://www.ghielectronics.com/docs/236/loader-tinybooter-update-g400
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?
[/quote]
We recommend that you should uninstall first, although it isn’t needed in almost PC.
@ 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?
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:
Downgrade the Loader on the Spider II from 4.3.7.7 to 4.3.4.0
Downgrade the Firmware on the Spider II from 4.3.7.9 to 4.3.6.0
That will make the Spider II compatible with my current SDK and since the SDK doesn’t change my Raptor wont need updating either…
Thanks.
(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 4.3.4.0 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.