Main Site Documentation

Error starting a DEBUG session


#1

I have installed TinyCLR 0.5.0 on a Discovery board.
VS2017 with drivers
I get an intermittent failure while starting debug (about 90% of the time), but occasionally it works.
Here is the Output of the attempt.

I also ran into this problem in netmf 4.2 and 4.3 Back when I was able to build the 4.4 code I had the same persistent problem. I was able to fix the problem and reported it, but it seems nothing was done.
In the logic that restarts the target the wait logic used a Thread.Yield() inside a 5 attempt loop. The problem with that is that if there are no waiting threads, the Yield will be ignored and the 5 attempts get eaten up too quickly.
Maybe this is a problem or not, but what is real is I cant start a debug session better than 1 out of 10 times.
I have tried reloading bootloaders, firmware etc.

If this is the problem can this be fixed? Or better yet publish the source code for the VS2017 debug code.

thanks

Looking for a device on transport ‘USB’.
Found device port ‘USB’ with ID ‘38a1e7f3-0ace-4ef9-bba4-efa5b12a47d3’ for transport ‘Usb’.
Starting device deployment.
Attempting to connect to device ‘USB:FEZ’: iteration 0.
Opening port ‘\?\usb#vid_1b9f&pid_0110#5&19aad0e4&0&1#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}’.
Attaching debugger engine.
Debugger engine attached.
Querying device assemblies.
Found assemblies:
- TinyCLRApplication1 v1.0.0.0.
- mscorlib v0.5.0.0.
- GHIElectronics.TinyCLR.Devices v0.5.0.0.
Generating device specific assemblies.
Deploying assemblies:
- TinyCLRApplication1 v1.0.0.0 with size 744 bytes at ‘C:\Projects\TinyCLRApplication1\bin\Debug\pe\TinyCLRApplication1.pe’.
- mscorlib v0.5.0.0 with size 76,636 bytes at ‘C:\Projects\TinyCLRApplication1\bin\Debug\pe\mscorlib.pe’.
- GHIElectronics.TinyCLR.Devices v0.5.0.0 with size 39,492 bytes at ‘C:\Projects\TinyCLRApplication1\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.pe’.
Total deployment size is 116,872 bytes.
Incrementally deploying assemblies to the device:
All assemblies on the device are up to date. No deployment was necessary.
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.
The debugging target and the debugger engine failed to initialize because of unspecified device errors.
The debugger engine thread has terminated unexpectedly with error ‘Could not reconnect to the debugging target after rebooting it.’.


#2

Does it happen regardless of project you try to debug?


#3

as far a I can tell so far, on the DISCOVERY board it does not matter what type
of program, I have used the skeleton default created as a new app, and something more complex.
All fail the same way/rate to startup.
I was working on the brainpad and it seemed better, I will try again.


#4

followup - the brainpad is failing about 50% of the time.


#5

If you hold down the LDR1 pin on either board when you apply power to it so that the app does not run, do you have better luck attaching the debugger?