Last modified August 30, 2016
This page is for solving common problems or issues.
It is very critical to
If in doubt, uninstall everything from GHI, the Microsoft NETMF SDK, and Microsoft Visual Studio. Then use the installation instructions; followed by, any necessary updates to the device's loader and firmware.
Two quick ways to use this document:
Programs using GHI Hardware libraries and .NET Gadgeteer programs will not run on the NETMF emulator.
The most common error in these cases is:
USB, by specification, should provide 500mA. Many devices on the market will either fail to provide 500mA or the voltage will drop drastically if that much power is drawn. When a HUB is used, all connected devices share/divide the available current.
NETMF and Gadgeteer boards require a lot of power; many peripherals/modules, like displays, as well as multiple modules increase the power demands; a project's requirement can exceed 500mA.
Therefore, it is strongly suggested to either use a power pack or use a powered USB hub.
Common symptoms of insufficient power are:
Occasionally the cable you use to connect a Gadgeteer module to your mainboard may be bad. If you are experiencing odd issues with a module, try using a different and shorter cable to see if the issues is resolved.
Windows uses device drivers to communicate with an attached NETMF device. Some factors necessary for establishing a working connection are:
Sometimes a driver must be installed manually; other times a driver may be installed with Microsoft Windows; this is version dependent, for instance, Windows 7 may not have a driver that is part of Windows 8.
The above picture shows that a "Universal Serial Bus Device" the G120 is in use. The G120 is used as an example, your NETMF may have a different name. In this case the necessary driver was supplied by Windows.
For versions of Windows without a built-in driver, GHI makes available two alternative drivers:
"GHI NETMF Debug Interface" USB controller/driver has successfully loaded after plugging a NETMF mainboard into a USB port of the computer.
Windows USB drivers load based on the powered-up device; so until you get the board powered you will not see the driver in the device manager. If you do not hear windows make a noise when you mainboard is plugged in and/or the powerlight on your mainboard does not turn on, then you may need a "powered USB hub," the USB cable may be bad, etc.
Most devices have two drivers, one loads when the device in normal use (needed for VisualStudio) and another when it is in loader mode (not TinyBooter, which uses the first driver). A typical “gotcha” happens when a user is trying to update the firmware. Once the device is switched to the loader mode, windows needs the second driver.
Note that "GHI NETMF Debug Interface" does not appear, & instead a different driver loads. In this case, the screen shot was from a member of the Cerberus family of boards and the driver loaded in this mode is "STM Device in DFU Mode."
USB and Application Deployment
If you have intermittent or constant failures in connection during the deployment of applications from Visual Studio, try resetting or power cycling your processor. In the example above, Visual Studio is having trouble connecting to the device. Pressing Reset interrupts the board (and any program it is running) and often allows Visual Studio to connect and proceed. See also in this document NETMF Troubleshooting
Some customers have had issues running the GHI Electronics' SDK due to USB problems. If all other USB advice, given above, has been tried, and been unsuccessful, then try the Serial Debug Interface instead. See the USB Client documentation which discusses the Debug Interface
Even with all the above suggestions and guidance, we find that problems with USB ports are some of the most common users face when trying to work with their hardware. There is a huge variation in the hardware implementations of USB in use in todays computers, additionally variations in versions of Windows drivers complicates the issue as well. Potential problems:
Things you can try:
The easiest way to understand “Ping” is this way, the host says “Are you there?” to the device and the device respond with “Yes I am here!”. This guarantees the USB drivers are installed and there is proper communication between the development machine and the device.
To ping the device, open MFDeploy tool, typically located at
C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe
Select USB for interface and the device should show in the list.
Click ping and you should see a response come back from the device, either TinyCLR or TinyBooter.
If you see "TinyBooter" after "Pinging..." instead of "TinyCLR" then your device does not have all the software loaded on it. Please follow the Firmware Update document for full details. Pay close attention to directions that involve "switches" or "jumpers" on your board, if you inadvertantly leave a switch (for example on FEZ Spider) in the wrong position, then the board may be responding with "TinyBooter" because of the switch; the switch position must be correct before doing the "Ping" test with MFDeploy.
If you do not have a commercial product that is locked to specific version, always use the latest software found at http://www.ghielectronics.com/support/.net-micro-framework
The first step is to make sure the version found on your PC matches the latest version available from http://www.ghielectronics.com/support/.net-micro-framework.
On the PC, the version installed can be determined by looking at release notes. Note that the the SDK package includes multiple SDKs. The release notes files are found at the following locations, you will need to consult http://www.ghielectronics.com/support/.net-micro-framework and replace the version strings below with the current version of the GHI package, examples:
For 4.3 (starting with "NETMF and Gadgeteer Package 2014 R2"):
C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.3 SDK\Release Notes.txt
C:\Program Files (x86)\GHI Electronics\GHI .NET Gadgeteer SDK\GHI .NET Gadgeteer Release Notes.rtf
C:\Program Files (x86)\GHI Electronics\GHI OSHW NETMF v4.2 SDK\GHI OSHW NETMF v4.2 Release Notes.rtf
C:\Program Files (x86)\GHI Electronics\GHI Premium NETMF v4.2 SDK\GHI Premium NETMF v4.2 Release Notes.rtf
All of GHI Electronics' Release Notes can be found with the SDK package.
When you have a version matching issue, you will see a message in the output window that looks like "ERROR!!!! Firmware version does not match managed code version!!!!"
To see version numbers of the software resident on your device, use mfdeploy's "Plug-in->Debug->Show Device Info" menu
Updating the SDK from the web site does not update the device; for that, you need to Firmware Update
If a deployed application contains a very tight infinite loop with no way for other threads/code to execute, it can be come difficult (if not impossible) for Visual Studio to attach to the TinyCLR interfaces necessary to re-deploy the app. The same problem can occur in devices that support PowerState.Sleep() where it is invoked very early in the program.
Resetting the device doesn't help as the minute it regains power it re-executes the currently deployed program. The first attempt you should make is to use MFDeploy and try to erase the application. If that fails you may have to reboot into tinybooter (see instructions in firmware update links: Firmware Update) and reload firmware (TinyCLR). During development, if you have a section of code that can potentially tie up the processor like this, you might want to surround the code with a safety net of some sort (wait for a button press, for instance) so that you can avoid the infinite code on power-up.
Due to the event driven nature of Gadgeteer programs this is more likely to be a problem with pure NETMF applications.
When deploying from Visual Studio for debugging, there is a small amount of RAM used on the device by the debugger. For applications that use lots of RAM (for example allocate large bitmaps), you may see out-of-memory errors occur while debugging (even at start-up if the memory usage is by static variable initialization); then if you just reset your device, without the debugger attached, the memory error does not occur. The only remedy for this is to reduce the storage requirements of your application -- dispose of objects no longer used, work with smaller buffers, etc.
This is close to verbatim from the community forum (https://www.ghielectronics.com/community/forum/topic?id=12929&page=1#msg131426). It explains why, even though you have a try-catch block from an exception, you see debugger info in the output window.
When a debugger is attached to the application the debugger is notified of all exceptions and has the first chance at dealing with the exception, the debugger then chooses to either break into the code, pass the exception on so that your code can handle it. In this case the debugger has opted to display the exception detail before moving one.
If you do not handle the exception then the debugger will get a second chance exception which will then stop the application with an unhandled exception.
If you have never tried to compile any NETMF or Gadgeteer programs in a newly installed programming environment (all SDKs just installed), and you receive the error: MMP : error MMP0000: 0x80131700 then there is a known work-around. This is do to a depence of NETMF on a file called "MetaDataProcessor.exe.config" which, in turn, is dependent on the version of ".NET" (not NETMF) installed on the system or because .NET is not installed on the computer.
This bug and the workaround (copied below) are described in the NETMF issue 221
The fix: go to the link NETMF issue 221, download the file MetaDataProcessor.exe.config then copy the file into a directory where the .exe file is located at "ProgramFiles (x86)\Microsoft .NET Micro Framework\vX.X\Tools", where X.X is the version of NETMF you are using (for example "v4.2"). Alternatively install ".NET Framework 2.0+ (3.5 SP1)". In Windows 8.1 you do this by adding the .NET 3.5 windows feature which is an option in the control panel - See more at this forum posting.
The CLR_E_PIN_UNAVAILABLE exception:
Due to the way NETMF writes EWR data, if your device is reset and/or powered off, the data may not be stored. There is an explanation of this in the Community Forum by Reinhard Ostermeier another good discussion of this is found in this Forum posting. GHI introduced a method to overcome this problem in the 4.1 and 4.2 SDK. NETMF added the same method as well.
Be sure to check the Developers' Guide for a processor for details on Extended Weak Reference for that processor (some processors may not have EWR support due to hardware limitations).