Visual Studio debugger not starting ... immediately detached after deploy

Archive
1

I have an EMX module to work with where the Visual Studio 2010 debugger seemingly deploys the program, but then doesn’t attach. This happens to me periodically where the fix is to redeploy the GHI Libraries (CLR, CLR2, Config). What causes the module to get into this state in the first place?

The properties of the project are set for .NET MF 4.1 (same as libraries I’m using), Startup object is correct, I click the green triangle (F5 - Start Debugging), and Studio reports status on the bottom line:

Preparing to deploy assemblies to device
Deploy succeeded
The debugging target is not in an initialized state; rebooting
The debugging target initialized successfully
Ready

but the debugger is immediately detached from the process and the program on the EMX module doesn’t appear to be running.

Why does this happen?

I’ve tried cleaning and rebuilding my EMX project, double checking I’m using the same runtime version of the GHI EMX libraries, exiting and restarting Studio, cycling power to my target, but I keep getting the same behavior.

I can ping the module via MFDeply while it is in this state where it reports OK, USB: EMX_EMX


Pinging... TinyCLR

I can read the device info using MFDeploy while it is in this state:

DeviceInfo:
  HAL build info: 4.1.2821.0, Microsoft Copyright (C) Microsoft Corporation.  All rig
  OEM Product codes (vendor, model, SKU): 255, 0, 65535
  Serial Numbers (module, system):
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
  Solution Build Info: 4.1.3.0, GHI Electronics, LLC
  AppDomains:
    default, id=1
  Assemblies:
    mscorlib,4.1.2821.0
    Microsoft.SPOT.Native,4.1.2821.0
    Microsoft.SPOT.IO,4.1.2821.0
    Microsoft.SPOT.Net,4.1.2821.0
    Microsoft.SPOT.Graphics,4.1.2821.0
    Microsoft.SPOT.Hardware,4.1.2821.0
    GHIElectronics.NETMF.SystemUpdate,4.1.6.0
    Microsoft.SPOT.Hardware.Usb,4.1.2821.0
    Microsoft.SPOT.TinyCore,4.1.2821.0
    System.Xml,4.1.2821.0

This has been happening routinely and the fix is to redeploy the (same) GHI libraries over again when this state hits.

What is likely causing this and how can I prevent the EMX module from getting into this state?

2

you are sure your program is not exiting at some point?

3

That’s a great question. I don’t know. I put a breakpoint on the first line of the program Main() and expect the debugger to stop there, but it doesn’t. So I guess it’s stopping before it gets to the first line of my program, but I don’t know how to trace that.

In other work with Studio (not .NET MF), you sometimes find that the debugger can get out of sync with various assemblies and you need to clean/rebuild. This seems like that kind of behavior to me, but I don’t know because I have less experience with EMX + NET MF, plus clean/rebuild doesn’t work in this case.

When I redeploy the MF firmware (CLR, CLR2, Config) and run the same program / same project in the debugger the breakpoint hits.

This has been happening to me on and off the past couple of months, but not consistently enough that I’ve had the time to track down the cause. If I find the source, I’ll post it here. Otherwise, just thought some of the more experienced EMX/MF/Studio users might recognize this and know the cause/fix.

4

This is a popular question.

In order to load a program to the device, Visual Studio must interrupt the program running on the device. In order to do this, the running program must release the CPU. If you program does not release the CPU, then you will experience the condition you described.

As part of the firmware reload, the resident application is erased. You are then able to load a new program.

When I experience this condition, I put a button at the beginning of the program, and wait for it to be press before starting the execution of the rest of the application. This allows me to make changes while I find the problem in my code,without having a problem.

5

If my program isn’t releasing the application, and not letting Studio interrupt, why does Studio report a successful deployment in the status bar at the bottom of the screen before detaching itself? Is there a watchdog timer or some call like the old Application.DoEvents() I need to put in my MF application to prevent this state?

I’m not sure this is the case because my program continues to function properly for lengthy periods (it normally runs 24-7) leading up to the programming event. I only encounter this problem on occasion when I go to deploy a new program, which is why I wondered if it is a synchronization issue with EMX, Studio, or assemblies.


Preparing to deploy assemblies to device
Deploy succeeded
The debugging target is not in an initialized state; rebooting
The debugging target initialized successfully
Ready
6

When you deploy the device is reset, your code is downloaded, then your code is started. After your code is started then the debugger tried to attach to the device. If the code on your device is running in a tight loop than the debugger might not be able to attach to it.

Think of it as trying to get the attention of a waiter in a restaurant. If the waiter is running as fast as they can from table to table they may never see you trying to call them to your table.

7

[quote] I wondered if it is a synchronization issue with EMX, Studio, or assemblies.
[/quote]

It is possible but unlikely.

If your are not releaseing the CPU this does not mean that the program will not work. It can be working fine. It just when you try to deploy new code you will see the problem.

Look through you code to see if you have a thread which is in a loop. Or there is a situation where you are handling Exceptions in a while loop which cause the exeception to keep occuring.

I am not 100% sure, but putting the statement “Thread.Sleep(0):” while you are in a loop may be enough to fix the problem.

Are you persisting any data in flash which may go bad and cause the application to operate erratic? I have seen bad code that put the MF core into a funny state and caused the debugger to detach.

If you load new code, then run it for a few minutes, can you then reload new software and debug?

Are you always using the same USB port to load?

8

just post some code that reproduces your issue

9

So, assuming this is some tight loop causing the problem sporadically (yes, I will identify/post-code when I identify it - please keep in mind this is a rather large multithreaded application), is there a more elegant way to wipe/halt my program rather than having to reload all the CLR,CLR2,Config assemblies?

There are various commands in MFDeploy, under Plug-in Debug menu. Would any of those do, without requiring redeploy of CLR,CLR2,Config if my software gets into this state?

Or is redeploy of CLR/CLR2/Config the only solution?

10

Try using MFDeploy to erase your application.

11

When I’m trying rlp code, I sometimes get into locked code too. My solution is to put a while loop at the beginning of my program.


bool wait=true;
while (wait)
   Thread.Sleep(500);

I then put a breakpoint at the sleep and modify wait to false.

When the code locks up, just reset the board and it will wait in the while loop, so you can upload your modified program.