Main Site Documentation

Problems while deploying! "Err: Unable to communicate with device, USB:Gadgeteer"


Hi all and happy new year :slight_smile:

Gents, I am frequently getting this error!!
“Unable to communicate with device, USB:Gadgeteer”

Also after I build my Gadgeteer project and when I press DEBUG, usually VS is getting stuck while it is
"Preparing to deploy assemblies to the device"

Why do I have this err and hanging??

VS 2010, Cerbuino Bee, 4.2


Can be many reasons. Type of the application (very tight loops, etc.) Is it specific to a certain app that you can show the code for?


Are you able to erase the program using MFDeploy?


@ PetaByte - Visual Studio may be regenerating the Gadgeteer friendly name after a reset, or a detachment of the debugger. This would cause a minute gap in communication forcing Visual Studio to regenerate the name as the generic USB:Gadgeteer because your device did not respond soon enough for Visual Studio. Under the Project Settings tab, and then under Microframework, just click the dropdown for Device, and the name should change from USB:Gadgeteer to something like EMX_EMX (for spider). Redeploy after switching this. If this is not the case, then the next logical culprit is a tight loop as Architect suggested.


Hi, thnx for the replies,

I don’t think it is because of tight loops!!

BTW: sometimes it doesn’t take more than seconds while “Preparing to deploy assemblies to the device” for same code

Any way, here is the code which record GPS NMEA raw data to SD Card :slight_smile:

// This code is grapping RAW NMEA data from GPS module,
// and store it into SD card...
// Last modification 1/1/2013, Tue, 8:18PM

using System.Collections;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Touch;

using Gadgeteer.Networking;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using Gadgeteer.Modules.GHIElectronics;

using System;
using System.IO;
using Microsoft.SPOT.IO;

namespace GadgeteerApp2
    public partial class Program
        private GT.Timer _timer;
        private string _root;

        void ProgramStarted()
            if (VolumeInfo.GetVolumes()[0].IsFormatted)
                _root = VolumeInfo.GetVolumes()[0].RootDirectory;
                _timer = new GT.Timer(5000);
                _timer.Tick += new GT.Timer.TickEventHandler(TimerTick);

            // Serial Reading


            usbSerial.SerialLine.DataReceived += new
            // ***
        void TimerTick(GT.Timer timer)
            string fileName = Path.Combine(_root, "DONETracksLogNMEA.txt");
            Stream stream;

            // GPS Reading
            int NumberOfBytesToRead = usbSerial.SerialLine.BytesToRead;
            byte[] readInputBuffer = new byte[NumberOfBytesToRead];
            usbSerial.SerialLine.Read(readInputBuffer, 0, NumberOfBytesToRead);
            // ***********

                stream = File.OpenWrite(fileName);
                stream.Position = stream.Length; //FM Not To Overwrite
                stream = File.Create(fileName);
            using(var writer = new StreamWriter(stream))
                // GPS writing to SD
                for (int j = 0; j < NumberOfBytesToRead; j++)
                    char a = (char)readInputBuffer[j];
                // ***

        void SerialLine_DataReceived(GT.Interfaces.Serial sender, System.IO.Ports.SerialData data)




@ PetaByte - what device are you using?


@ PetaByte - Did you ever resolve this - I have trouble deploying even an empty project !!


I have the same issue on my Mountaineer Eth with NETMF 4.2 QFE2 and VS 2010.

I deployed the following “stupid” test program one time, and it is still running (LEDs blinking and serial port rattling). Since that, VS can’t connect any more, and also MFDeploy.exe can’t ping or erase the device.

I thought I could simply erase the flash memory using the ST DFU Tester. Selecting “Erase” and then clicking “Go” displays “success” immediately, but after that, when I release the boot pin and restart the board, the old program still starts to run. How do I properly erase the flash memory?

Thanks so much for your help! I am still pretty new at this…

using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.Threading;

namespace MainboardTest1
    public class Program
        public static void Main()

            var tm = new System.Threading.Timer(timerF, null, 0, 5000);

            System.IO.Ports.SerialPort s = new System.IO.Ports.SerialPort("COM1", 9600);

            while (true)
                s.Write(new byte[] { (byte)'a', (byte)'b', (byte)'c', (byte)'d', (byte)'\n' }, 0, 5);

        private static void timerF(object state)
            OutputPort redLed = new OutputPort((Cpu.Pin)77, false);
            OutputPort greenLed = new OutputPort((Cpu.Pin)75, false);
            OutputPort blueLed = new OutputPort((Cpu.Pin)78, false);



I’d go back through the entire firmware deployment steps, that certainly should clear everything.


while (true)
s.Write(new byte[] { (byte)‘a’, (byte)‘b’, (byte)‘c’, (byte)‘d’, (byte)’\n’ }, 0, 5);

      // add the following line 


A very tight loop, results in the debugger having trouble attaching to the running program. Putting a Sleep() into the loop should fix the problem.


…or start the timer might also allow some scheduler time and debugger to get in. But the “stupid” comment led me to believe that it was known what they did wrong :slight_smile:


I did try that. Re-installing the firmware (using DfuSe Demo, according to did not change anything - I assume that it only overwrites the firmware and does not erase the application?
As I wrote before, I tried to erase the complete flash using DFU Tester, but that didn’t work either. I have no idea why.

Agreed. Yet my board is preventing me from deploying a new program in the first place, so I can’t apply that fix now.

I only realized that afterwards, obviously. I assumed that the firmware itself would reserve some scheduler time to cater for the debugging/deployment interface…

Thx all for your help!


I don’t have a mountaineer board, although I do have a Cerb (uses same chip) but have little experience in tight loop issues except in USBizi. It is possible that the firmware update process leaves an application intact, but I can’t be sure - it doesn’t in USBizi, you erase and it erases everything.

Can I suggest that you give MFDeploy a try? Connect the board to the PC, have MFDeploy open and set to USB, then hit reset on the board and hit F5 in MFDeploy to connect? If that’s successful, then ERASE the application from MFDeploy. Might need to try a number of times…


Even hitting reset didnt help MFDeploy to connect :frowning:

As a last resort I connected a JTAG adapter (see picture). Luckily this worked, so I could erase the flash via JTAG. So, the board is not really bricked :slight_smile:
After erasing, I could re-install the firmware, run a (proper) sample program, and connect MFDeploy alright.

I still do not understand why ST DFU Tester does not erase anything, though. That would be much simpler than connecting JTAG this way.