Deployment problems using FEZ Spider II and VS 2013

Hello everyone.

I’ve been having issues while trying to deploy/debug my Gadgeteer application to my FEZ Spider II.

I go to the Device Manager (Win7) and for what I can see, the board is being detected (GHI NETMF Interface), and then I go to the project’s properties, on the .NET Micro Framework section, I select USB as transport and, of course, it automatically selects the board I have connected (G120_Gadgeteer because I didn’t change the friendly name).

I updated the Firmware to 4.3 before trying to make any movement.

But this is what I get whenever I try to debug/deploy:

[em]Looking for a device on transport 'USB’
Starting device deployment…
Iteration 0
Opening port \?\usb#vid_1b9f&pid_0102#5&5acd33d&0&10#{d32d1d64-963d-463e-874a-8ec8c8082cbf}
Attaching debugger engine…
… cannot attach debugger engine![/em]

and on the error list it says: [em]Unable to communicate with device USB:Gadgeteer[/em]

Or maybe i’m being super stressed and not seeing the error right below my nose, or maybe is something in my code, who knows?

I need a little bit of help. I’d appreciate it :’( I’m basically new in this so I still have a lot to learn.

Anyway, here’s the code:

public partial class Program
        InterruptPort port;
        bool interrupted = false;

        // This method is run when the mainboard is powered up or reset.   
        void ProgramStarted()
            Debug.Print("Program Started");
            if (port == null)
                Debug.Print("Configuring Interruption Port");
                Cpu.Pin pin = GT.Socket.GetSocket(2, false, breakoutTB10, null).CpuPins[3];

                port = new InterruptPort(pin, true, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeBoth);
                port.OnInterrupt += port_OnInterrupt;
                Debug.Print("Interruption port configured.");
            Debug.Print("Waiting for an interruption");

        void port_OnInterrupt(uint pin, uint level, DateTime time)
            interrupted = level == 1;
            if (interrupted)



Start a new project, netmf console for now. Do not add any code. Go to transport and select USB. Can you deploy now?

Only connect the red power module and the main board, no other modules.

I did it that way, but the same thing happened, once again :frowning:

Looking for a device on transport ‘USB’
Starting device deployment…
Iteration 0
Opening port \?\usb#vid_1b9f&pid_0102#5&5acd33d&0&6#{d32d1d64-963d-463e-874a-8ec8c8082cbf}
Attaching debugger engine…
… cannot attach debugger engine!

Any other devices you can try? Try a different USB port?

1 Like


USB port is 2 or 3 version ?
Do you use a hub ? with additional power or not ?

1 Like

@ martin92 -

It can be:

  • Device is in TinyBooter mode, make sure you can send Ping… TinyCLR
  • The current application gets stuck => need to re-flash firmware. Or just hold LDR1 to access tinyBooter, then erase deployment by MF Deploy.
  • Refresh the port communication in VS2013, just click on USB and select your name device in the combo box. Sometime you still need refresh although it looks like correctly.
  • Try without hub
1 Like

@ martin92 -

You did not mention what version of Visual Studio you are using.

I believe in the past using VS 2013 I would (on occasion) have to switch the Device: Transport: from USB to Serial and then back to USB.

Click on Project select Properties. .NET Micro Framework in the menu list.

Worth a try? Good luck.

1 Like

Thank you guys for the feedback.
I’m using VS2013 Ultimate by the way.
I decided to uninstall and reinstall .Net MF, the Gadgeteer Core and the SDK.
Then I decided to reinstall the both TinyBooter and TinyCLR updates via FEZ Config.
I tried with a .Net MF Console Application and it deployed successfully. I tried with a simple Gadgeteer Application, such as led blinking with a timer, only having the USB Client DP as one of the modules attached to the mainboard, and it also deployed good.

But the thing I’m not getting now is, as soon as I try to connect another module (in this case, is a Breakout TB10), my PC won’t detect the board at all (no sound, not even seen in the Device manager).
Im assuming it has to do with a sensor I have connected to the breakout (a saintsmart End-Stop sensor), but I already unplugged it and my PC detects the board, and after few minutes, my PC doesnt detect the board anymore, and then all of a sudden, it detects the board again (as if i was plugging it and unplugging it)

Now I can’t deploy anything on the board. An as soon as I try to ping the Board with FEZ Config, it says:
[em] Pinging…
Failure - Device is not connected or not responding. [/em]

1 Like

@ martin92 -

Shot in the dark…

Try a different ribbon cable for the USB Client DP (Power module).

1 Like

The sensor you have connected to the breakout, or the wiring you’re using, is shorted out. The USB port is shutting off. I’d say you’ve wired GND and 5v or 3v3 incorrectly. Triple check your wiring.

Fundamentals: If you connect the Fez to the PC, check what appears in device manager. If nothing, then you’ll never be able to deploy to the device. I suspect in your “failed” state with the TB10 connected, you’d see nothing.

1 Like

Thank you Brett. I was now able to deploy the application.
I used to have a FEZ Spider I before this one, and I remember I used to Incrementally deploy applications flawlessly, but with this one (FEZ Spider II), it’s mandatory to manually delete the previous application and then deploy the new one, or you have to reinstall both TinyCLR and TinyBooter updates to deploy an application, otherwise they won’t deploy at all, not sure if that’s how this board works or if that’s an actual issue.

Awesome, are you going to let us know what it was? :slight_smile:

Your must-erase-and-reload scenario does not sound correct. There is usually no need to do that - just deploy, change your code, then redeploy. Prove that by creating a simple blinky program and deploying it with changes over several times, only with simple modules connected. You may be finding your code is running in a loop that doesn’t allow the debugger to attach to the running process to update the deployed app; one way around this is to build in say a 10-sec wait (or wait for a button press) at startup of your app, and you hit deploy in VS then reset your board and the debugger can connect and update the app.

1 Like