Anyone have any other resolution to this other than ‘flee to another machine, and hope it works!’?
I have tried multiple machines, multiple USB ports, multiple OS, multiple versions of Gadgeteer SDK (including latest) but have no luck here. Dead in the water at the moment. There has to be a more reliable way to get VS to stay connected to Gadgeteer (using Cerb at the moment, but I don’t think Spider is any different).
After it deploys the app (verified successful) and claims to establish a debug session, it says “The debugging target runtime is loading the application assemblies and starting execution”, and that is it. No breakpoints hit (in fact, it says assemblies are not loaded) and it appears as though VS has lost all connectivity to the device (rebooting the device has no affect on VS, it still sits there in run mode as if about to debug the app).
OK, I have collected enough detail now to officially be frustrated. My Cerb devices simply will not talk.
I have tried all of the following:
SDK 2013 R3 w/ firmware 4.2.x
SDK 2014 R4 w/ firmware 4.2.x and 4.3.x
Windows 8.1 (multiple USB ports tried)
Windows 7 (different machine, all USB ports tried)
VS 2012 Express
VS 2012 Pro
2 different Cerb devices (v1.1 and 1.2)
2 different power modules (SP and DP)
3 different USB cables
…and all sorts of matrix combo of all of the above to NO AVAIL
I’ve also tried reloading the boot loader just for kicks.
When I plug in my Spider, everything is peachy. Connects, deploys and debugs apps, no prob! It’s like a breath of fresh air. Why Cerb hates on me so bad?
Also BTW, FezConfig and MFDeploy both see the Cerb boot up, can ping it, but can’t get device info from it, so I suspect something is wrong independent of VS. VS does see the Cerb, successfully deploys the app! ([em]blinky LED hello world works when deployed[/em]), but will NOT establish a debug connection as documented in this thread. Just stops and silently abandons the connection to the device right as it should launch into the program and breakpoints.
I’m especially surprised this issue exists after so many of us have been using Cerberus, and clearly I am not the only one who has hit this issue (a year ago it was an issue, this is not new). Maybe it’s just my unlucky stroke to hit 2 PC’s that just don’t want to play. But will a 3rd be any different? New/Different PC hardware is the only known, documented solution, but not a [em]proper[/em] solution!
Why on this green earth can’t the cerb “just work”, like my Spider? I just want to write apps, not fight the dang device.
Uh oh. I’ve got another machine that, in Dat’s words, is “not happy with Cerberus”. It is another Dell Latitude E6320, the same model of laptop I had troubles with at the start of this thread.
Short of driving in to work to pick up a different laptop did we ever get to the bottom of the Cerberus error where Visual Studio hangs at “The debugging target runtime is loading the application assemblies and starting execution”?
And while I know this fix did not work for Dat I found that taking the hard-drive out of my Dell Latitude E6320 laptop and putting it into an ‘identical’ laptop fixed thing. I.e. I changed none of the bits on the laptop nor the device but in a different machine it works. Very mysterious.
I good and bad news to report to close the loop on my issue.
I am not 100% sure the cause, but here is what I know. 3 different PC’s would not run the cerb for me as described, HOWEVER, I flashed my firmware with NETMF 4.2 selected in FezConfig. This MIGHT be have been the key in my case (I really wanted to use 4.2 instead of 4.3). I was running the latest SDK’s which include both 4.2 and 4.3 support, and Fez Config allows you to go either way, but I believe v4.2 was the root of all evil here.
Everything is working great after I did the following:
Install GHI NetMF SDK 2014 R5
Update the bootloader using STDFU to be current (4.3.4.0)
Flash the firmware using Fez Config set to NetMF 4.3 (not 4.2) and current version (4.3.6.0)
Finally working again, on all my PC’s that were failing earlier.
