Spider won't deploy AGAIN ! is this going to get any better?

Hello guys,
I came here to actually vent, because I’ve wasted well over 8 hours today fighting with my spider to get it to deploy properly from VS2010 or MFDeploy… it simply won’t …
in VS it just hang, i have to play the reset trick to get it to deploy, the problem it doesn’t work all the time because i have to hit the reset button in a precise moment which i can’t get to every time…
so I’ve tried to deploy a simple NETMF hex that I’ve saved from before using MFDeploy… so it starts deploying and get almost to the end and then it throws an error saying can’t deploy… and frankly I’m tired of this problem… and i just need to know if this is going to be address at all… i mean we can only ignore this for so long…

imagine you are working developing something and suddenly you start dealing with this non sense, you loose time focus and just gave up on what you are doing… i just hope GHI is taking this seriously and coming with a permanent fix.
same result on the following configs:

Spider with 41 and stable 41 firmware.
Spider with 42 and July 23rd Beta firmware.

Tried deploying Gadgeteer no go… simple new project 41 and 42
tried deploying Standard NetMF no go… simple new project 41 and 42

i am out of tricks and I’m very very very frustrated… I’m sure you can tell.

Jay.

Did you try erasing first? It sounds like you have a tight loop that’s preventing the deploy. However, I’m fighting something similar with a Hydra tonight. It’s not liking me including certain resources. 4.3 is supposed to be dedicated to fixing these types of problems. I’m praying with you!

Trust me i tried it all…
Erasing, firmware re-flash…everything you can think of and more :slight_smile: it just won’t work… i get it to deploy occasionally with the reset trick but that is not good enough, because i have to keeping hitting that reset button while it is deploying at random times until it takes, so i get one deploy in about 10 to 15 tries and that’s more than 8 minutes of back and forth for each deploy, i get to the point that i forget what i was fixing in code…

man 4.3 is too far out there… i hope this gets fixed when GHI 42 is out… or at least GHI should dedicate time to this and find a WORKAROUND FOR US to use until a real fix is out… instead of letting us hanging …

Edit: I know GHI have the expensive tools to find out what this issue is (maybe they already know and it is serious enough that might cause a recall Ohhh :frowning: ) and they should use the tools to find us a workaround, if i were them i would dedicate more time to this then anything…

That should be this week. :slight_smile: Also, QFE2 will be right on it’s heals and that will have things using the new USB drivers which I think are the cause to many of these problems. Hang in there!

it sounds like i should join my boards and hang :slight_smile: so there you have it:

Pinging… TinyCLR >>> hanging …

There are thousands of spider users so what you are describing is very uncommon or you will see it all over the forum :slight_smile:

We are of course always available to improve if we are to reproduce what you are seeing. We just need to know how to repro the problem on our end.

@ Gus - I know Ian have been having similar issues on the Hyrda while doing some beta work for me. He’s using your RC version and I’m using the one before that. I have no issues where he’s fighting lots of deploy issues.

@ Ian - Perhaps you can give GHI a small snippet that’s blowing up for you but not me?

Gus: that might be true but how many of those come here daily? And how many are actively developing ? The fact of the matter is this issue has been there for as long as I can remember, 2 years now… Since the days of usbizi…
Here is one of the many results of searching " deploy" in the forum : http://www.tinyclr.com/forum/topic?id=1522&page=1

If you use the board to actively deploy and redeploy in a small interval it gets to a point to stop… Try it for 8 hours build fix and deploy for 8 hours straight and it’ll fail.

Tell me what to do to help you debug the issue and I’ll do it…

I just want to see this fixed!!!

When I was having this problem yesterday, it took a reboot of my PC to fix it. Since my computer is on 24/7, I’ve found that this is necessary every so often to clean up the debug/usb connections. That’s why I have high hopes for the new USB drivers. Like Jay, I’ve had these problems regularly forever and I’ve just learned to deal with them but sadly I’ve lost countless hours of productivity in the meantime.

I was having the same deployment problems tonight and I was able to solve it by removing some modules from the Gadgeteer designer that I wasn’t using yet. I’m going to do some more tests to see if I can reproduce. Might have been a one-time problem or it might be a conflict that’s happening with modules. I had CP7, Bluetooth, Joystick, & RFID connected. I have found recently that if you have a Bluetooth module connected but not setup in the designer that it will cause similar problems and has made me more aware of keeping modules connected that I’m not actively using. As far as a code snippet goes, I haven’t found any code that reproduces this every time.

I had to butt in here…
I have always had deploy issues but I just ‘lived’ with it. However, it seems to be getting worse.
Deploy hangs using MFDeploy or when deploying from visual studio. MFDeploy crashes or hangs and sometimes visual studio restarts.

Something new has happened which did not happen before. In the past I could press the Spider reset button and start over. Now when I press the reset button my PC display goes black and I have to re-boot the PC. In fact, yesterday I received the blue screen of death.

I beleive it happens when GHI .NET Micro Framework USB Debugging Interface disappears when pressing the reset buttton.

Partial debug output received
************** Exception Text **************
System.Runtime.InteropServices.COMException (0x8001010D): An outgoing call cannot be made since the application is dispatching an input-synchronous call. (Exception from HRESULT: 0x8001010D (RPC_E_CANTCALLOUT_ININPUTSYNCCALL))
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at System.Management.SinkForEventQuery.Cancel()
at System.Management.ManagementEventWatcher.Stop()
at Microsoft.SPOT.Debugger.UsbDeviceDiscovery.remove_OnDeviceChanged(DeviceChangedEventHandler value) in c:\depot\current\CLIENT_V4_1\Framework\Debugger\Streams.cs:line 790
at Microsoft.NetMicroFramework.Tools.MFDeployTool.Engine.MFDeploy.Dispose(Boolean disposing) in c:\depot\current\CLIENT_V4_1\Framework\Tools\MFDeploy\Library\MFDeploy.cs:line 155
at Microsoft.NetMicroFramework.Tools.MFDeployTool.Form1.Form1_FormClosing(Object sender, FormClosingEventArgs e) in c:\depot\current\CLIENT_V4_1\Framework\Tools\MFDeploy\Application\MFDeployForm.cs:line 706
at System.Windows.Forms.Form.OnFormClosing(FormClosingEventArgs e)
at System.Windows.Forms.Form.WmClose(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

After receiving the above I ran the GHI NETMF v4.1 and .NET Gadgeteer Package and flashed the firmware.

Sometime later I received the blue screen on a deploy from visual studio and I pressed the reset button. (I tried to stop the deploy from visual studio but it would not stop)

Not blaming anything but the only new module I was using is the WiFi RS21. Having a blue screen sort of prevents me from experimenting. (I am not using tight loops)

Just my thoughts…
Have a great day!

@ willgeorge - the reset (BSOD) is a known problem which has been fixed in QFE2 which GHI is working furiously to get out to us. :slight_smile:

I think we are talking about different things here, so yes BSOD is a known issue in Microsoft 4.2 SDK (not GHI) that will be resolved in short weeks. Not being able to latch to the debugger is related to having dead loops in the application, causing it not to have time to get to the debugger. Use events with proper programming and this will never be a problem. 4.2 QFE2 also improved boot time so this may also help in attaching VS.

We are also looking to improve as always.

never had the BSOD…

back to my issue, when i can’t deploy my application… i always revert to MFDeploy to erase and i try to deploy a simple test hex file that is nothing more then a simple NETMF console application.

Even after reboot i still can’t deploy…

GUS i have a solution here that has mainly few empty project, that seems to refuse to deploy, if you want i can zip and send it to you so you can try it on your system… it may be that VS2010 gets corrupt if you have a Solution with multiple Projects in it, even if i unload the projects from the solution, i still can’t deploy the only one left.

IS THERE A Software that i can use to see monitor this process better and find out what’s causing the issue?

Thanks.

This sound like a problem in the project not in the device, like you have it set to 4.1 but then the firmware is 4.2 or other problems. Or even a project error.

If you have a “project error” then please forward this to microsoft as this is not related the device itself https://netmf.codeplex.com/

You miss understood Gus,
That was just a situation i ran into yesterday, not the root cause, and me describing it here is to help you reproduce the issue not to tell me go to Microsoft. And my issues always happen on a single solution that deploys fine until it won’t, so if you really want to help please stop focusing on a single test like the one above a look at the big picture, as you can see from the link on my first post, this issue has been there from usbizi days, and acknowledged by mike but and no one offered a fix ever since.

I’m sure others have experienced similar issues and just like me they don’t report it right a way, but learn to deal with it for a while but when it starts to eat at your productivity, then we say enough…

So please if you really want to help show me how to debug and uncover the issue… You can always contact me on my e-mail found at my profile if you want me to try a different firmware… Maybe one that displays debugging info or a USB driver that displays debugging info so we know where it hangs, surely you have one of those right?

Thanks.

What would be most helpful in solving this problem would be more info from the compiler. The generic “unable to connect to hardware” is not always an accurate description of the problem. I know for a fact that this is caused by more than just tight loops. Saturday, I was getting this error and I could deploy just fine from one project but I couldn’t from another. If we could get lower level exception info we could help debug the issue better.

You mean this https://netmf.codeplex.com/workitem/1589

and this https://netmf.codeplex.com/workitem/1216

and this https://netmf.codeplex.com/workitem/1209

Please vote if these effect you.

Gus and others here is another way to break the spider…
Open MFDeploy 4.2 and hit erase when it finishes and reboots the board hit erase again, and voila the board hangs and will require a firmware re-flas to get it back…
Please please before you tell me to check with Microsoft, give me a GHI tool to erase my developed application and if that doesn’t break it I’ll report the issue to Microsoft.

I’m seeing this kind of ‘hangs’ too, I need to press the reset button after each 5 to 10 deploys. I’m using latest 4.1 version on EMX module.

@ Jay Jay: don’t know if it’s related to your problem but I hibernate my PC each day and only do a full restart each 2 weeks or so. Problem is that the NETMF driver seems to hate this on a 64bit machine (this was working fine on a 32bit machine). Now, before I hibernate I make sure I first disconnect the EMX, if I leave it connected while hibernating, I will never be able to connect with the EMX again until I restart Windows.

@ Jay Jay - please see last reply and we will try the double erase.

@ WouterH - this maybe better once we switch to WinUSB soon.