Sad story: I’m working on a .NET MF app before lunch and everything seems fine: I can make changes to the app, download the code to our custom board with a G400S, run and debug the code. After lunch, I can’t talk to the board at all. When I try to download the app, VS says there are deployment errors and I should check my hardware. FEZ Config gives me this:
The PC can see the G400 in the WIndows 7 devices applet. VS2013 can see the G400 in the Project Properties. I can ping the board with FEZ Config, I’ve erased the application with FEZ config and tried to “Reboot CLR” like FEZ config says to do. FEZ Config said both operations were successful. Of course, I’ve rebooted the PC and the G400 several times.
Seems like the G400 is stuck in some mode that doesn’t allow downloads but I’m not sure how to get it back where it needs to be.
I pulled a new board from stock and got similar (but not identical) results.
Of course it is the day before a Holiday so any suggestions will be doubly appreciated.
In VS, select project, right click >> project properties >> .net Micro Framework Tab.
Change Transport from USB to Serial, then change back to USB.
Retry running/debugging/starting the app via VS, i.e. click the ‘Start’ button.
Well this just gets weirder and weirder. I know about switching the project transport from USB to Emulator and back. I’ve done that many times in the past also and tried it again for this issue many times with no luck. After several tries, I was able to reload the firmware with FEZ Config. Still no luck. So, I tried a different laptop. Guess what? It worked. Twice. And now I’m back to not being able to down load programs but with new symptoms.
When I hit the green arrow in VS, the output window says it successfully deployed the assemblies to the device and then says it is starting the device deployment but all it does is iterate until it fails with this error:
Error 1 Device not found or cannot be opened - USB:SN001
The weird thing is the Device is SN05 not SN001. SN001 is the board I was using before. And the project properties show a USB connection to SN05. I’ve built, cleaned and rebuilt many times but it seems to want to deploy to a device that is not connected?
I seem to have fixed the problem, at least for now, but there still is something important I clearly don’t understand. When I reflashed the .NET MF firmware with FEZ config, I left the “friendly name” set to the default “Gadgeteer”. Previously it was SN005. In spite of multiple rebuilds, cleans, project property transport changes, reboots of anything that could be rebooted; VS didn’t change whatever it needed to change so it could download my app to a G400 with a different friendly name.
If anyone knows what you have to do in VS when the hardware friendly name changes, I’d sure like to know.
I’m not sure I can swear this is completely correct but when VS gives an error about can’t deploy to device name “XYZ” and device “ABC” is the one that is actually connected (see details above), the only thing that has worked for me is switching the transport in project properties to “emulator”, rebuilding and then switching the transport back to “USB”. Switching the transport without rebuilding, which does fix a lot of mysterious errors, didn’t work here.
Gene - I finally hit the wall on this also. Here is what I did to recover!!!?
Ran into problem where I could not deploy to a device that had previously been deployed to, debugged, etc. The device was on the shelf for a few months and most likely there were some minor code changes that would need to be deployed.
When I went to build, deploy, debug (Pushed the Start button) I would see the Iteration 0…. When it got close to 50 the device would reboot, VS would connect, deploy and in the end display “There were deployment errors.” The error list would show: Device not found or cannot be opened - USB:Gadgeteer
Doing: project, right click >> project properties >> .net Micro Framework Tab showed device as
G120_G120, selecting transport = serial then back to USB still showed G120_G120.
Closed VS, rebooted and hit Start button again. No Luck.
Opened fez cconfig, G120_G120 connected, re-updated firmware 4.3.8.1 friendly name = Gadgeteer (from what I remember?). Everything loaded fine. At bottom of Fez it showed G120_Gageteer is connected.
Hit start button on VS. No luck.
Cleaned solution, hit start button and everything worked….Holy thankful crap!
Checked: project, right click >> project properties >> .net Micro Framework Tab showed device as
G120_Gadgeteer….
If you see “The device is in Loader mode”, meaning firmware is not running and VS can not communicate to the device. So don’t try to use VS to communicate to device.
There few reasons that cause " firmware is not running", Sometime because you hold loader button and hit reset by accidently. If this case happened, just hit reset without holding any buttons.
Or sometime, from FEZ Config->Advanced->Reboot TinyCLR also get you back to TinyCLR mode.
Very rarely is, somehow firmware is corrupted, just re-flash firmware.
VS can not deploy application once friendly name has changed. From my experience, all you need to do is, refresh friendly name in VS properties -> select usb ->select new friendly name.
Thanks Dat for your input. A few things to make clear:
1.) The device is not in loader mode. Boot_0, Boot_1 & Mode pins all in proper state to run user application. The device is running .netMF 4.3.8.1 and my application was running just fine. I was tryng to connect with VS to load new user application and debug.
2.) Again…NOT tinyClr but .netMF 4.3.8.1
3.) I never changed ‘Friendly Name’…AFAIK…I think you may be confusing friendly name with Device?..again I tried everything, which has worked in the past, but this time a different wrinkle was thrown in and more steps (shots in the dark) were required to overcome.
I do not like “Shooting in the dark” for solutions to this. I/we the community deserve an explanation of what’s under the hood, the mechanics of what causes this and how best (easiest) to overcome!
I guess your application has something that block the device. Try with simple application, just print out some text.
In NetMF4.3 we have TinyBooter and TinyCLR modes. I meant TinyCLR mode, not TinyCLR OS.
As your post, sometime it is G120_G120, sometime it is G120_Gadgeteer, so I guess friendly name was changed, this also cause VS can’t deploy your app if no refresh USB port.
if not in case (3), as I remember TinyBooter mode is always G120_G120, no matter what friendly name is, and of course, you can not deploy the app if in TinyBooter mode.
Back to 1, just re-flash and deploy small -simple application to see what happen.
We have hundreds of custom boards deployed with the G120. Most of the time we deploy code with VS >> Start. We also do RFU and of course can use fezConfig to load the app…but we use the VS debug features to check that new boards are working correctly, i.e. a great/easy way to pre-test (see debug output) prior to deployment.
We only see this problem once in a while…I do not know how to re-create, it just sometimes happens?
As said earlier, I was able to get past the problem using the technique I posted earlier.
I do not know how to get the board (G120) back into the Iteration 0…Iteration 59 state and get cannot deploy message, etc.
Usually, up until today, doing the USB refresh worked. Only the technique, in previous post, got us back up and going.
There is nothing we ever do to change friendly name…we do not even care. We just want it to work.!
I am sure I could load the simple program and it will work as all is synced…now.
But I would assure that at one point or another…loading same app hundreds of times the same problem will occur.
My contention is there is something in VS, the GHI sdk or .netMF causing this.
I am just asking for inside info of what all links must consist for a good deployment.
DAT - I created new simple project as you suggested in your post.
I am able to deploy and debug with no problems.
I went back to my production project and cleaned the solution, selected “Emulator” as deployment transport, then built the solution. Went back and selected “USB G120_G120” then pressed start button.
Went thru iteration 0…60, then connected and deployed assemblies.
Then a VS dialog popped-up saying “There were deployment errors. Continue?”, I clicked Yes.
VS finds the debugger, the app starts and everything is good.
The problem is…everytime I want to start a debug session I have to wait 60sec (iteration 0…60) and go thru the process above.
If I look at the VS Error List I see: Device not found or cannot be opened - USB:Gadgeteer
No matter how many times I try cleaning and rebuilding VS expects to deploy/debug USB:Gadgeteer
I have looked thru the Build Output and see lines like that below when the assemblies are being compiled and such.But nothing specific to the transport?
C:\Program Files (x86)\GHI Electronics.NET Gadgeteer SDK\Modules\USBSerialSP\NETMF 4.3
At the very end of the Build Output I see:
3>Device not found or cannot be opened - USB:Gadgeteer4>------ Deploy started: Project: cdLib2, Configuration: Debug Any CPU ------
cdLib2 is the last class library in my project that I added.
My solution has the main (console application) and two class libraries cdLib & cdLib2.
I had never considered that these class libraries also needed to have the deployment transport set, i.e. I always just looked at main and called it good.
I checked all three project for deployment transport.
main had deployment transport = USB G120_G120
cdLib had deployment transport = USB G120_G120
cdLib2 had deployment transport = Emulator … I changed deployment transport = USB G120_G120
Clicked the start button… and holy mackrell…deployment and debug as expected (no iteration 0…60).
So, the solution appears to be to make sure ALL projects within a solution have deployment transport = (whatever you want), also do a clean and rebuild, finally got me over the hump.!!
