VisualStudio 2017 debugging issue

Using a UCM Dev Board Rev E with a UC5550
Libs version 1.0.0-preview1
Using USB Client for App deploy

I cannot debug/deploy reliabiy when using my UCM Dev Board.

I have a gut feeling that it is because in order to reset my board it requires pressing the Reset button twice in rapid succession.

Is this normal for the Dev Board?

Not normal! How do you know that it needs twice? What happens when you hold reset down and observe the device manger? Anything else is connected to the dev board? Display?

Are you using preview1 or preview2?

Using a UCM Dev Board Rev E with a UC5550
Using a UD700 Rev A
Using the Dev Board SD Card reader

UsingLibs version 1.0.0-preview1
Using USB Client for App deploy

Device Manager
Universal Serial Bus devices
UC5550

Dev Board USB Client connected to PC USB Port

  1. First power on from Dev Board USB Client
    Universal Serial Bus devices
    shows UC5550

My app runs as expected.

  1. RESET buton press once and release (Length of time is a normal button press)
    Device Manager shows
    Universal Serial Bus devices
    UC5550

My app runs as expected.

RESET buton press and hold

Universal Serial Bus devices does not show in the Device Manager as long as the Reset Button is held pressed.
Universal Serial Bus devices showing UC5550 returns when the button is released.

When VS hangs or reopens with a new screen
VS closes and reopens with my app (NOT opening with a new start screen)

Device Manager shows
Universal Serial Bus devices
UC5550

As far as “How do you know that it needs twice?”

Found by accident. If I pressed the button twice quickly the board would reset.
Has happend on different occasions and I have no idea why.
Even when using different app code.
As far as I can recall the Device Manager always showed the UC5550.

Are you using preview1 or preview2? Both, without and change in the code.

Total deployment size is 154,172 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.

Severity Code Description Project File Line Suppression State
Error Device not found or cannot be opened - USB:UC5550

VS Community 2017 Version 15.8.5 hangs here or VS closes itself and restarts with my application.

It does not matter if I use Libs version 1.0.0 or version 1.0.0-preview1

Device Manager shows Universal Serial Bus devices UC5550 as it should.

Using Windows 10 Pro

Looking for a device on transport ‘USB’.
Found device port ‘USB’ with ID ‘5adb8a6b-47a8-4f1a-8eb4-48bd3c52078a’ for transport ‘Usb’.
Starting device deployment.
Attempting to connect to device ‘USB:UC5550’: iteration 0.
Opening port ‘\?\usb#vid_1b9f&pid_500d#6&e224814&0&1#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}’.
Attaching debugger engine.
Debugger engine attached.
Querying device assemblies.
Found assemblies:
- mscorlib v1.0.0.0.
- GHIElectronics.TinyCLR.IO v1.0.0.0.
- GHIElectronics.TinyCLR.Drawing v1.0.0.0.
- TinyCLR-SDcardtest v1.0.0.0.
- GHIElectronics.TinyCLR.Devices.Display v1.0.0.0.
- GHIElectronics.TinyCLR.Devices.I2c v1.0.0.0.
- GHIElectronics.TinyCLR.Devices.Spi v1.0.0.0.
- GHIElectronics.TinyCLR.Devices.Gpio v1.0.0.0.
- GHIElectronics.TinyCLR.Devices.Storage v1.0.0.0.
- GHIElectronics.TinyCLR.Native v1.0.0.0.
Generating device specific assemblies.
Deploying assemblies:
- TinyCLR-SDcardtest v1.0.0.0 with size 13,088 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\TinyCLR-SDcardtest.pe’.
- mscorlib v1.0.0.0 with size 72,284 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\mscorlib.pe’.
- GHIElectronics.TinyCLR.Devices.Display v1.0.0.0 with size 5,748 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Display.pe’.
- GHIElectronics.TinyCLR.Devices.Gpio v1.0.0.0 with size 4,808 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe’.
- GHIElectronics.TinyCLR.Devices.I2c v1.0.0.0 with size 5,380 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.I2c.pe’.
- GHIElectronics.TinyCLR.Devices.Spi v1.0.0.0 with size 5,356 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Spi.pe’.
- GHIElectronics.TinyCLR.Devices.Storage v1.0.0.0 with size 4,260 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Storage.pe’.
- GHIElectronics.TinyCLR.Drawing v1.0.0.0 with size 18,328 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Drawing.pe’.
- GHIElectronics.TinyCLR.IO v1.0.0.0 with size 20,696 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.IO.pe’.
- GHIElectronics.TinyCLR.Native v1.0.0.0 with size 4,224 bytes at ‘C:\Users\Will George\source\repos\TinyCLR-SDcardtest\TinyCLR-SDcardtest\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe’.
Total deployment size is 154,172 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. (Never initializes)

Sometimes all is well!

I can live with it so not a real problem for me unless I really need to debug.
For now I use text messages sent to the LCD screen.

Do you have some code that I could use to do a reset from the application?

Thanks!

I would use preview2 exclusively, we fixed a large number of bugs that were present in preview1.

You can reset the board using GHIElectronics.TinyCLR.Native.Power.Reset in the native assembly.

One thing you can try instead of pressing reset twice, is to hold down LDR1 (which should be SYS C) while powering the board or resetting once to prevent your app from running, then try to deploy.