Vs2010 & Framework 4.1 issues

I can’t get my fez mini working after firmware update. I did exactly what has been described on the side. Pinging works and the device capabilities gives the correct firmware. So I assume that the firmware upgrade has been executed correctly.

When I make a new project in csharp express 2010 and use the standard program with the blinking LED. I get no error in csharp express 2010 but in the lower left corner it says that the debugging target is not in the initialized state.
At this moment the led on the fez mini is dimmed. And nothing seems to work.
If I now do a ping then the program on the fezmini starts executing. :o

=> conclusion compilation and download of program seems to work but the debugging stuff has a problem.

Sidenode : I am using fresh install of visual c# express 2010 under vmware. There is nothing else on the virtual disk. This has been done for the previous versions and worked like a charm. So I don’t suspect this being the problem.

Any ideas?

Make sure you uninstall all of the previous NETMF stuff before you install the new FEZ SDK and NETMF SDK. Then, update the firmware. Also note the difference in path name:
C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.1 SDK (NEW)
C:\Program Files (x86)\GHI Electronics\GHI NETMF v4.0 SDK (OLD)

If you are selecting the firmware to upload with your uploader, you may have mistakenly gone to 4.0 instead of 4.1

@ Chris,

The firmware on de the device is correct. That has been checked. It is for the moment :
So with MFDeploy I can do a ping and get as a result “tinyclr”.

It is the debugging that doesn’t work. The download of the program seems to work because when I do a ping with MFDeploy after the program has been downloaded it starts running correctly (the led goes on and off) :o

You did make sure your project is set to build to the USBizi and that it is deploying with 4.1, correct?

@ Chris

yes I am sure. Like I stated before the download worked because the program runs after a power cycle.

Did you move the new debug dll they provided in the install folder to your .net micro folder?

@ Chris

That I did not do. To what directory should I copy this …cordebug.dll to?

its in the readme. but it should be “program files.net micro framwork\4.1\tools” or something like that.

The t3ext file with instruction is in the install folder with the dll.

[quote]NOTE: This SDK is based on .NET Micro Framework V4.1 (NOT 4.0)

If you used the GHI Beta release for v4.1, please see section at the bottom.

To use this release, make sure to note the following:

  1. It requires Visual Studio 2010 Express or other 2010 versions.

  2. .Net Micro Framework SDK v4.1

  3. Next, you can install GHI NETMF v4.1 SDK.

  4. Firmware, Tinybooter (if applicable) and libraries are compatible for each SDK release and they may not work with previous releases. (See release notes for version info).
    Make sure to update all your software components including firmware and library assemblies. Otherwise, your managed application will not run at all or run incorrectly.

  5. (HIGHLY Recommended) You may experience problems with Visual Studio debugging and attaching to your hardware.
    To solve this issue:
    First, make sure that Visual Studio is closed.
    Copy Microsoft.SPOT.Debugger.CorDebug.dll (Included) to your installation path.
    This will overwrite the older version.
    By default, the path is “C:\Program Files\Microsoft .NET Micro Framework\v4.1\Tools”

  6. If you have problems with Visual Studio loading/running older projects, try making new projects and copying your files.

Note to previous Beta users:
-Due to changes in release SDK, make sure to uninstall previous GHI SDKs and make sure the SDK folders are deleted.
-Previously Beta user had to copy a new Device.targets file. You must copy the old file back. If you are not sure, uninstall .Net Micro Framework 4.1, then make sure the Device,targets is deleted. Reinstall SDKs when done.
-Make sure to copy the new Microsoft.SPOT.Debugger.CorDebug.dll[/quote]

Thanks man dont have it on my work machine.

By the way, we will have an official fix to the SDK from Microsoft very soon so there is no need to copy the dll

No problem :wink: