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

Gus_Issa · September 27, 2012, 2:07pm

We test express and non-express.

Note that if you leave your code with zero free time, like if dead-while-loops, you will leave no time for the debugger to latch easily to VS.

sq77 · September 27, 2012, 2:12pm

Is that new behavior?

Gus_Issa · September 27, 2012, 2:22pm

This has always been the same. NETMF is managed language so you should always use events if you want things to run smooth. Even if you have loops, add a little sleep in it to let the rest of the system run without stressing it.

Brett · September 27, 2012, 4:57pm

@ SQ77, you say you can’t even deploy once, do you really mean that ? You’ve never put your code on the device?

As Gus says, without time for the debugger to attach VS won’t be able to connect. The simplest way I find to get around that, and it may not work in the 4.2 SDKs very well (I’m still on 4.1) is to press reset while starting the deployment process. YMMV. The alternative is to get into MFDeploy and erase your code that way, but you also need to get into the debugger.

Mike will chime in soon with his approach to this, which from memory is adding in some time or a button check as the first thing the app does, so you always get a chance to stop it from going into the tight loop portion of your code which gives the debugger time to attach

Gus_Issa · September 27, 2012, 11:37pm

to be clearer, it will attach but not easily. You may need ot hit F5 couple times.

AndVas · September 28, 2012, 9:50am

I have the same problem on my laptop with Windows 7 Pro 64-bit.
Another laptop running Windows 7 Pro 32-bit has no issues.
32-bit OS installed on VMWare (host OS is Windows 7 64-bit) doesn’t help.

On my 64-bit OS:
I can do anything I want with my Cerbuino using MFDeploy or STDFU tester.
But I have constant problems with deploying and debugging using Visual Studio. I got several types of misbehavior: “An error has occurred: please check your hardware”, “Device not found or cannot be opened”, debugger starts but doesn’t hit any breakpoint,
Couple of times board reset during deploy made it work.
Yesterday I noticed that this “reset trick” made it work for some time: until OS reboot. That makes clear the fact that x64 drivers still have a lot to work on.
So I decided to use my old laptop with 32-bit OS (but it’s a real pain - slow processor and tiny screen).
I hope you guys have a plan how to fix these 64-bit issues…
But great job, anyway!

Justin · September 28, 2012, 9:53am

@ AndVas - Do you have VMWare installed on the machine having deployment issues?

AndVas · September 28, 2012, 10:07am

@ Justin
Yes

sq77 · September 28, 2012, 10:31am

No I have deployed before. But since I got the latest SDKs I can’t deploy even once after having wiped the device clean (and putting the latest tiny booter on it).

sq77 · September 28, 2012, 10:34am

If it’s helpful to know, when I write the firmware in MFDeploy and then get the error at the end with the signature validation, pinging it will show TinyBooter. But if I reboot just the CLR (still in the MFDeploy UI) I can then ping and get TinyCLR as a response.

When I first did that I was excited because I thought visual studio would start deploying, but unfortunately no

Aron_Phillips · September 28, 2012, 1:19pm

sq77:

Brett:

@ SQ77, you say you can’t even deploy once, do you really mean that ? You’ve never put your code on the device?

As Gus says, without time for the debugger to attach VS won’t be able to connect. The simplest way I find to get around that, and it may not work in the 4.2 SDKs very well (I’m still on 4.1) is to press reset while starting the deployment process. YMMV. The alternative is to get into MFDeploy and erase your code that way, but you also need to get into the debugger.

Mike will chime in soon with his approach to this, which from memory is adding in some time or a button check as the first thing the app does, so you always get a chance to stop it from going into the tight loop portion of your code which gives the debugger time to attach

No I have deployed before. But since I got the latest SDKs I can’t deploy even once after having wiped the device clean (and putting the latest tiny booter on it).

What is the Tinybooter dfu file number? Is it TinyBooter_4_2_3_0.dfu or TinyBooter_4_2_3_1.dfu? Plus verify that you click “Create from Map” and then Erase and then Go or any minor change (down to byte) can cause the system to not function.

sq77 · September 28, 2012, 5:21pm

Aron:

sq77:

Brett:

@ SQ77, you say you can’t even deploy once, do you really mean that ? You’ve never put your code on the device?

As Gus says, without time for the debugger to attach VS won’t be able to connect. The simplest way I find to get around that, and it may not work in the 4.2 SDKs very well (I’m still on 4.1) is to press reset while starting the deployment process. YMMV. The alternative is to get into MFDeploy and erase your code that way, but you also need to get into the debugger.

Mike will chime in soon with his approach to this, which from memory is adding in some time or a button check as the first thing the app does, so you always get a chance to stop it from going into the tight loop portion of your code which gives the debugger time to attach

No I have deployed before. But since I got the latest SDKs I can’t deploy even once after having wiped the device clean (and putting the latest tiny booter on it).

What is the Tinybooter dfu file number? Is it TinyBooter_4_2_3_0.dfu or TinyBooter_4_2_3_1.dfu? Plus verify that you click “Create from Map” and then Erase and then Go or any minor change (down to byte) can cause the system to not function.

Version 4_2_3_1
And I do “Create from Map”, following the tutorials on this site exactly.