"Preparing to deploy..." takes ages

Hi Folks, As of Saturday, one of my projects does not deploy any more. VS just sits there saying "preparing to deploy" and never finishes. Since that, all other projects now sit for about 20-30 seconds before actually starting the deploy. This will happen with existing projects as well as a brand new one. I have just upgraded to the newest firmware and SDK (think it was 4.2) and the problem is still there. Everything deploys ok, it just takes forever making debugging a bit of a faf. Setup is a normal Win7 x64. Using the USB cable supplied with netduino. Any suggestions? thanks

nobody? It's impossible to work on them now as it takes too long to deploy stuff. I have 3 netduinos, happens on all of them. To build and start the MS emulator is instant. any ideas welcome

Have you tried erasing the device with the MFDeployment Tool? I had a similar problem where device application opened the usb port on start up.

One of them was totally wiped and flashed (I bricked it somehow) a while back, not tried anything recently with either of them. Sadly I've moved to another platform to complete the project as this was just far too painful

nobody? It's impossible to work on them now as it takes too long to deploy stuff.
I have 3 netduinos, happens on all of them. To build and start the MS emulator is instant.

any ideas welcome

I've had this issue happen to me from time to time. It is why I built a box with a switch on the USB power lines to power-cycle the Netduino. I found this cleared up 99% of the deployment issues I had.

-dan

cool that that works, even if it is a bit of a typical Microsoft fix [start help desk voice]have you rebooted sir?[/end helpdesk voice] I really am bummed about it as VS is by far the best IDE - Arduino has an IDE with functionality which is only rivalled by notepad and is slightly quicker than my coffee grinder. For those reasons, I dislike it. Busy giving Fez a whirl now. Waiting with baited breath for the first signs of...

cool that that works, even if it is a bit of a typical Microsoft fix [start help desk voice]have you rebooted sir?[/end helpdesk voice]

I really am bummed about it as VS is by far the best IDE - Arduino has an IDE with functionality which is only rivalled by notepad and is slightly quicker than my coffee grinder. For those reasons, I dislike it.
Busy giving Fez a whirl now. Waiting with baited breath for the first signs of...

I happen with my VS2010 and ND+ too... I workaround the problem disconnecting and reconnecting the USB cable.....(that means reboot the ND)...

Unfortunately, this issue with the .NET Micro Framework SDK/driver isn't easy to patch via the device. If you ever experience it, here are a few pointers: 1. If you have trouble deploying, press the reset button on your Netduino. 2. If that doesn't work, unplug and re-attach your Netduino to your PC. 3. If all else fails, erase your current app using MFDeploy and the bootloader mode of your Netduino. Crispin--sorry, I didn't see this message until now Chris

I found unplugging the USB cable waiting a few seconds, then reconnecting the board solves this for me. It happens every 3rd or 4th deployment for me.

I found that this is affected by the application code. One of my programs runs three fairly busy threads, and when that is running it is quite difficult to deploy to the device. I added code so that the test button fires an interrupt handler that sets an exit flag so I can signal the threads to exit. As soon as I use this, it becomes easy to redeploy. You can also use MFDeploy to erase your application with similar effect. Chris, I don't know whether this is within your purview, but is there any way this can be baked into the tools? I should point out that it often takes a few tries to erase a runaway program but I expect you know this.

Just thought I would chip in my way of getting around these problems ... which did start with adding a switch to a USB cable, but the thing that seems to stop me having to use the switch is not using the VS debugger ... simply deploy from VS (can be assigned to short-key) and then use MFdeploy for debug output unless you actually need line-by-line. I also wrote a simple exe referencing mfdeploy that I can just run to auto connect & listen .... crashes are fewer and generally far between, more usual from doing something silly in the code!

I discovered that you can sometimes lock your board in a while loop state when not using a Thread.Sleep. Using the OnBoard Button as an interrupt has completely rid me of these issues. Using the onboard LED as well lets you know if your board is locked up. If only we had an Application.DoEvents right? Anyways, this works for me...

        private static SPI.Configuration config;
        private static SPI spi;

        private static bool runningState;

        public static void Main()
        {
             // Setup SPI
             config = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, true, false, 500, SPI.SPI_module.SPI1);
             spi = new SPI(config);

            // Set up Interrupt
            InterruptPort btn = new InterruptPort(Pins.ONBOARD_SW1, false, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptEdgeHigh);
            btn.OnInterrupt += new NativeEventHandler(btn_OnInterrupt);
            OutputPort led = new OutputPort(Pins.ONBOARD_LED, false);

            // Set Running state
            runningState = true;
            led.Write(true);
            Debug.Print("Running");

            while (runningState)
            {
                PollController();
            }
            
            // Shut'er down!
            led.Write(false);
            Debug.Print("Exited!");
        }

        static void btn_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            runningState = false;
        }

Just thought I would chip in my way of getting around these problems ... which did start with adding a switch to a USB cable, but the thing that seems to stop me having to use the switch is not using the VS debugger ... simply deploy from VS (can be assigned to short-key) and then use MFdeploy for debug output unless you actually need line-by-line. I also wrote a simple exe referencing mfdeploy that I can just run to auto connect & listen .... crashes are fewer and generally far between, more usual from doing something silly in the code!

That's very interesting. I don't suppose you'd consider sharing your auto-debug-listen tool? These days I power cycle the N+without even thinking about it and that does the trick for deployment, but I have noticed that some of my code only works when not being watched by the debugger, which tells me you're on to something. This problem is the proper domain of the VS team, but I doubt I'll live long enough to see them fix it so I'm very keen to use something else to listen to Debug output.

That's very interesting. I don't suppose you'd consider sharing your auto-debug-listen tool? These days I power cycle the N+without even thinking about it and that does the trick for deployment, but I have noticed that some of my code only works when not being watched by the debugger, which tells me you're on to something. This problem is the proper domain of the VS team, but I doubt I'll live long enough to see them fix it so I'm very keen to use something else to listen to Debug output.

I can indeed ... its nothing special and in VB. You could just use MFDeploy straight off, although you will have to go through the process of choosing USB and connecting each time which is why i ended up making this exe which just does it on load. There's some bits in there I was using to test http and tcp/ip function on the device also and various code commented out I think from exploring automated deployment from the exe aswell ... but you should be able to take what you need, its been a while since ive looked at this but if I recall it was only a few lines of code using the MFDeployEngine reference that you actually need. http://tagbak.net/jlmf.winui.rar

hth and let me know any probs.
Jamie.

Not sure I understand this... Every time my board locks, MFDeploy can't connect.

if the board is locking/crashing then you wont be able to deploy because its too busy doing whatever is causing it to lock ... you should reboot and deploy before it gets a chance to lock up again, you may need to hold the reset button down for a few seconds to give you that little bit longer to deploy the update ... or failing that wipe it and re-flash.

This error started happening to me as I was configuring my motorshield. There was a piece of code that broke and it must have recieved some bad code that would lock up the device so that I could not connect or deploy any new code. I tried all the strategies atleast 100 times waiting 5 seconds to deploy, then waiting 5 seconds to connect usb, all the various methods that everyone in these forums have written. I gave up yesterday and ordered a new arduino uno r3. Today I sat back down and said, okay, I'm going to get this thing working. I finally found the following: http://alhardy.com.a...etduino-Go.aspx This solved it. I had to boot the board to DFU mode, then use the tools to erase and load the tinyclr.dfu. Now I'm back up and running. My suggestion to Netduino, is this: Put a reset button or jumper on the next board so that if it gets stuck in a loop or error, there is a way to clear the program that is running or reset back to factory.... Or throw another button on their to do an actual reset.. Could have saved me hours...

Hi hoquet,

My suggestion to Netduino, is this: Put a reset button or jumper on the next board so that if it gets stuck in a loop or error, there is a way to clear the program that is running or reset back to factory.... Or throw another button on their to do an actual reset..

Thank you for the feedback. We will be enabling the current button as a reset button in an upcoming update. That will start over the board, but wouldn't help in this kind of scenario. [Unplugging and reattaching the Netduino Go would do the same thing.]

We are working on an app which will erase the current app on the board. To use it, you'll press and hold the pushbutton on your Netduino Go while plugging it in, press the "erase application" button, and then be good to go. This capability was designed into the Netduino Go hardware design.

Please let us know if you have any other troubles,

Chris