Any plan of improving Visual Studio Extension?

[Dave_McLaughlin]

You might be missing some then. FOTA lists a number of them. Check your build has them included.

Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.IO.TinyFileSystem’ (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly ‘AtlantisDevelopment.SDCardDriver’ (1.0.0.0)
Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Storage’ (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Gpio’ (2.2.0.5000)
Assembly: FOTA (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Update’ (2.2.0.5000)

Save for the SD card.

Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Spi’ (2.2.0.5000)
Assembly: AtlantisDevelopment.SDCardDriver (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.Gpio’ (2.2.0.5000)
Assembly: GHIElectronics.TinyCLR.IO.TinyFileSystem (2.2.0.5000) needs assembly ‘GHIElectronics.TinyCLR.Devices.Storage’

[Mike]

Something to try… Use a powered USB hub between the PC and the device. Might help with the failure after a period of time.

[dcyonce]

Dave,
That is the issue. Sometimes TinyCLR Deloyment will deploy the entire set of assemblies.
And then sometimes … it doesn’t deploy at all. But it thinks it deployed them.
When the Debugger runs, it says it cannot find the missing assemblies.

[dcyonce]

Thanks Mike !
I’ll try that. I tried one from Amazon that was powered, but it didn’t make any difference. I’ll get a new one and try again.
Don

[Dat_Tran]

try erase all to see if that help.

[dcyonce]

Erase Application doesn’t make a difference.
Erase All doesn’t make a difference.

The problem is the Visual Studio Extension. It’s VERY buggy.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '75aef62e-6324-4950-9da1-97127d128dc2' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:SC13048': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#7&2ac184dc&0&1#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

Found debugger!
Create TS.
Loading Deployment Assemblies.
Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.
Cannot find any entrypoint!
Done.
Waiting for debug commands...

At this point … TinyCLR Config says “No assembly found on device”.

[Mike]

Don

I am in the process of developing a program for a Flea. It drives a stepper motor for a watch winder. I have been happily compiling, loading and debugging without any issues.

There is something in your solution/project that is messed up…

First, have you tried building a new solution and adding your files to this solution? This has been known to help in the past.

If it is possible, you can send me your solution directory and I will take a look and see if I can get around the problem. No promises…

[Dat_Tran]

Did you add any reference? If so, check every reference to see if there is yellow exclamation mark.

[Dat_Tran]

Or if you can share the project to us to reproduce the issue.

[dcyonce]

Doesn’t seem to matter what application.

But, I figured out one of the issues. When I have a solution with multiple projects, the VS Extension can get confused. When I set the active application, the VS Extension keeps trying to deploy the previously selected application.

Looks like this has been a problem for many years.

Link failure: some assembly references cannot be resolved!

I have had less than consistant experiences running multiple executable projects within the same solution. No problems with class library projects. The problem I typically see happens when I set a project as the active project and deploy it. The prior active project is deployed, instead of the one I just selected, with similar results to yours. I avoid multiple executable projects within the same solution.

Once the TinyVLR Visual Studio Extension thinks the assemblies are updated, it’s very hard to get it to deploy the correct set of assemblies.

If I had the source … I would find these FRUSTRATING bugs !

[dcyonce]

Dat Tran,
Here are a couple more issues I have found:

TinyCLR support for “foreach of a string”
With the following code anywhere in an application, Visual Studio gives an error message : CS7038 Failed to emit module ‘XXXXX.XXXX.XXXXX’: Unable to determine specific cause of the failure.
Took me a long time to find this one since Visual Studio doesn’t tell you where the problem is or give any hint…

string s = "some string";
foreach (char c in s)
{
	Function( c );
}

TinyCLR will cause Visual Studio to crash
Anytime an application being debugged runs out of heap, TinyCLR debugger locks up and Visual Studio crashes. Upon reload, Visual Studio recommends disabling TinyCLR Extension to prevent crashes.

This one is fairly easy to reproduce. Create a recursive loop, allocate too much memory, etc.

Haven’t been able to pinpoint the other issues. I’ll post them if I can get them cornered.

– Don

[dcyonce]

Dat Tran,

Here’s some more deployment logs that demonstrate one of the problems with TinyCLR Visual Studio Extension.

After erasing the Application using TinyCLR Config … I try to deploy and run an application.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
	- Writing sector 1 (2,048 bytes).
	- Writing sector 2 (2,048 bytes).
	- Writing sector 3 (2,048 bytes).
	- Writing sector 4 (2,048 bytes).
	- Writing sector 5 (2,048 bytes).
	- Writing sector 5 (2,048 bytes).
	- Writing sector 6 (2,048 bytes).
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

As you can see, the TinyCLR Visual Studio Extension ONLY wrote the first 6 sectors of the application! Where is the rest !!! … the VS Extension skipped them entirely.

The next time I attempt to deploy, it writes another 12 sectors. But, still not the entire application.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
	- Writing sector 7 (2,048 bytes).
	- Writing sector 8 (2,048 bytes).
	- Writing sector 9 (2,048 bytes).
	- Writing sector 10 (2,048 bytes).
	- Writing sector 11 (2,048 bytes).
	- Writing sector 12 (2,048 bytes).
	- Writing sector 13 (2,048 bytes).
	- Writing sector 14 (2,048 bytes).
	- Writing sector 15 (2,048 bytes).
	- Writing sector 16 (2,048 bytes).
	- Writing sector 17 (2,048 bytes).
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

Each time it deploys a little bit more, but never the entire application.
And each time, the Debug output has errors:

Found debugger!
Create TS.
Loading Deployment Assemblies.
Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.
Cannot find any entrypoint!
Done.
Waiting for debug commands...

And from then on … it thinks the application has been deployed. But it still hasn’t deployed the entire application. So … the debugger still cannot find an entry point.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

And now … the TinyCLR Visual Studio Extension is completely screwed. It WILL NOT deploy the application correctly.

So … now no matter what application I attempt to deploy. The VS Extension skips deployment entirely.

Here’s another log after I opened a new solution and attempt to debug it.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'd0f63d17-5a57-4cd2-b380-17e5ed8860ee' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#6&3a1f35c0&0&3#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- MemoryTest v1.0.0.0 with size 848 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\MemoryTest\bin\Debug\pe\MemoryTest.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\MemoryTest\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\MemoryTest\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 79,608 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => GHIElectronics.TinyCLR.Native 
	- Address: 0x0805A3A8 => MemoryTest 
Deploying assemblies:
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

As you can see … it will not deploy that NEW application either. At this point the VS Extension is completely confused and will not deploy anything.

What else can I send you that will help you guys FIX the TinyCLR Visual Studio Extension ?
Thanks for your help !

– Don

[Mike]

@dcyonce

TinyCLR support for “foreach of a string”

Known issue. Been around a long time. Would be interesting to know why this is hard to fix.

I only see this issue once a project.

[Mike]

@dcyonce

TinyCLR will cause Visual Studio to crash
Anytime an application being debugged runs out of heap, TinyCLR debugger locks up and Visual Studio crashes.

Another known problem.

[dcyonce]

Hmm … is there a list of “known problems” or should I start one

[Mike]

Issues · ghi-electronics/TinyCLR-Libraries

[Dat_Tran]

@dcyonce

As you can see, the TinyCLR Visual Studio Extension ONLY wrote the first 6 sectors of the application! Where is the rest !!! … the VS Extension skipped them entirely.

This doesn’t mean the extension deployed incorrectly. if you already deployed 1MB, then on the second deploy, if you changed only few bytes somewhere in first 2KB in the source code, meaning only first 2KB need to be rewrite, so you will see only first sector 2K shown. That will help reducing time when you deploy large projects.

You can check by erase deployment and redeploy again, you should see all data will be deployed.

@dcyonce

As you can see … it will not deploy that NEW application either. At this point the VS Extension is completely confused and will not deploy anything.

Every time you deploy your project, the sector you see may different, depends on how much you changed in your source code. And if you don’t change anything from the last deploy, no sector shown from the output window, this is done by purpose, not a bug.

Back to your issue, it could be a bug in extension, or something with your project setup.

So we need to know how to reproduce the bug first. If you can share your project to us, we will take a look quickly.

Or if your project is private or sensitive that can’t be shared, just make a simple project, reproduce your issue on that project and send to us.

[Dat_Tran]

Also, the sectors may shown:

sector 1
sector 7
sector 8
sector 10
…

they are also not a bug, because depends on where you changed in your source code. It doesn’t need to be 1,2,3,4,5,6,7…

[dcyonce]

Dat Tran,
Thanks for your help. Let me clarify…

The logs in the previous post are consecutive. NO changes to my code at all.
All consecutive deployments within a few seconds.

Here’s what I did :

• Erased the application using TinyCLR Config

• Attempted to deploy an application (119,484 bytes)
  TinyCLR only deployed part of the application (sectors 1-6)

• Immediately attempted to deploy again.
  TinyCLR only deployed another 11 sectors this time.
  Still not the entire application.
  Each time, the debugger complains “Cannot find any entrypoint!”

• Attempted to deploy the same application again.
  Unfortunately, TinyCLR VS Extension is now confused and will not deploy anything.

• Switched to an empty application with only a few lines of code.
  Attempts to deploy all fail. TinyCLR VS Extension is now hopelessly confused and always thinks everything is just fine and the entire application is deployed (no matter what application I attempt to deploy).

• Gave up. Went to bed. I’ll try again tomorrow.

Next morning … rebooted computer in order to reset TinyCLR USB driver and VS Extension.

• 1st attempt to deploy original application … deployed part of the application (sectors 9-52), but TinyCLR hung at “Waiting for device to initialize”. Waited about a minute.
  Pressing RESET on the Pico … VS Extension still hung.
  Unplug Pico and plug it back in … VS Extension still hung.
  Hit STOP within Visual Studio. 5 to 10 seconds later. VS Extension is stopped and Visual Studio back to normal.
  The VS Extension hanging at this point sort of makes sense. It hasn’t deployed the entire application. It’s going to fail at some point.

Here’s the deployment log:
It deployed another part of the application (but not all), sectors 9-52, but hung up at “Waiting for device to initialize”.

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '82cbf1ca-75e9-4f7a-b7a7-d70dcaada635' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#8&304af94c&0&2#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
	- Writing sector 9 (2,048 bytes).
	- Writing sector 10 (2,048 bytes).
	- Writing sector 11 (2,048 bytes).
	- Writing sector 12 (2,048 bytes).
	- Writing sector 13 (2,048 bytes).
	- Writing sector 14 (2,048 bytes).
	- Writing sector 15 (2,048 bytes).
	- Writing sector 16 (2,048 bytes).
	- Writing sector 17 (2,048 bytes).
	- Writing sector 18 (2,048 bytes).
	- Writing sector 19 (2,048 bytes).
	- Writing sector 20 (2,048 bytes).
	- Writing sector 21 (2,048 bytes).
	- Writing sector 22 (2,048 bytes).
	- Writing sector 23 (2,048 bytes).
	- Writing sector 24 (2,048 bytes).
	- Writing sector 25 (2,048 bytes).
	- Writing sector 26 (2,048 bytes).
	- Writing sector 27 (2,048 bytes).
	- Writing sector 28 (2,048 bytes).
	- Writing sector 29 (2,048 bytes).
	- Writing sector 30 (2,048 bytes).
	- Writing sector 31 (2,048 bytes).
	- Writing sector 32 (2,048 bytes).
	- Writing sector 33 (2,048 bytes).
	- Writing sector 34 (2,048 bytes).
	- Writing sector 35 (2,048 bytes).
	- Writing sector 36 (2,048 bytes).
	- Writing sector 37 (2,048 bytes).
	- Writing sector 38 (2,048 bytes).
	- Writing sector 39 (2,048 bytes).
	- Writing sector 40 (2,048 bytes).
	- Writing sector 41 (2,048 bytes).
	- Writing sector 42 (2,048 bytes).
	- Writing sector 43 (2,048 bytes).
	- Writing sector 44 (2,048 bytes).
	- Writing sector 45 (2,048 bytes).
	- Writing sector 46 (2,048 bytes).
	- Writing sector 47 (2,048 bytes).
	- Writing sector 48 (2,048 bytes).
	- Writing sector 49 (2,048 bytes).
	- Writing sector 50 (2,048 bytes).
	- Writing sector 51 (2,048 bytes).
	- Writing sector 52 (2,048 bytes).
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

• Immediately attempted to deploy and debug again. No luck this time either.
  Completely different set of error messages this time,

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '82cbf1ca-75e9-4f7a-b7a7-d70dcaada635' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#8&304af94c&0&2#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Assemblies not successfully deployed to the device.
Deployment to the device was not successful.

• Switched to a different board (SC13048Q Dev Board instead of a Pico.)
  This board already has the entire application deployed successfully from a few days ago.
  EXACTLY the same problem. TinyCLR VS Extension hangs at “Waiting for device to Initialize”.

Here’s the log :

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '82cbf1ca-75e9-4f7a-b7a7-d70dcaada635' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:SC13048': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#8&304af94c&0&2#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
Restarting interpreter.
Attaching to device.
Waiting for device to initialize.

** Rebooted the computer.**

Attempt to deploy on the original Pico. WOO HOO !
TinyCLR VS Extension now deploys the rest of the application (sectors 53-59).
Success at last after a PC reboot.

Here’s the log

Looking for a device on transport 'USB'.
Found device port 'USB' with ID 'e0b4af4a-8387-4df7-89eb-526a5c57b779' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:Syzydyne': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5012#8&304af94c&0&2#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Generating device specific assemblies.
	- uBlox Communications v1.0.0.0 with size 1,336 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\uBlox Communications.pe'.
	- AtlantisDevelopment.TinyCLR.Core v1.0.0.20871 with size 11,420 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.Core.pe'.
	- AtlantisDevelopment.TinyCLR.GprsGnss v1.0.0.0 with size 15,076 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\AtlantisDevelopment.TinyCLR.GprsGnss.pe'.
	- mscorlib v2.2.0.5000 with size 72,560 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\mscorlib.pe'.
	- GHIElectronics.TinyCLR.Devices.Gpio v2.2.0.5000 with size 4,880 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Gpio.pe'.
	- GHIElectronics.TinyCLR.Devices.Uart v2.2.0.5000 with size 8,012 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Devices.Uart.pe'.
	- GHIElectronics.TinyCLR.Native v2.2.0.5000 with size 6,200 bytes at 'E:\Projects\Mobile PC Manager\ChassisTracking\Mobile Devices\uBlox Communications\bin\Debug\pe\GHIElectronics.TinyCLR.Native.pe'.
Total deployment size is 119,484 bytes.
Incrementally deploying assemblies to the device:
Allocating assemblies:
	- Address: 0x08047000 => mscorlib 
	- Address: 0x08058B70 => AtlantisDevelopment.TinyCLR.GprsGnss 
	- Address: 0x0805C654 => AtlantisDevelopment.TinyCLR.Core 
	- Address: 0x0805F2F0 => GHIElectronics.TinyCLR.Devices.Uart 
	- Address: 0x0806123C => GHIElectronics.TinyCLR.Native 
	- Address: 0x08062A74 => GHIElectronics.TinyCLR.Devices.Gpio 
	- Address: 0x08063D84 => uBlox Communications 
Deploying assemblies:
	- Writing sector 53 (2,048 bytes).
	- Writing sector 54 (2,048 bytes).
	- Writing sector 55 (2,048 bytes).
	- Writing sector 56 (2,048 bytes).
	- Writing sector 57 (2,048 bytes).
	- Writing sector 58 (2,048 bytes).
	- Writing sector 59 (704 bytes).
Assemblies deployed. There are 6,396,228 bytes left in the deployment area.

• Everything works just fine. I can now deploy and debug any application to any board … for a while that is. In about 20-25 minutes the VS Extension get confused and starts giving random errors and will not function once again.

A few clues …

• At first I thought I must have a bad USB port or some other device on the USB bus is interfering. Nope, the problems are not isolated to a single computer.
  Seeing that other people on the GHI Forum had the same set of issues helped focus my efforts on isolating the problems.

• The problem seems to be focused on TinyCLR Visual Studio Extension and/or the USB Driver.

• Once it is confused, a PC reboot helps … but not always. Sometimes it works great for a few deployments after a reboot … sometimes it works great for an hour or more.

• If I take the “partially deployed” Pico to another computer and attempt to deploy the EXACT SAME application the same way, it will succeed (until that copy of TinyCLR VS Extension gets confused and gives up).

• It does not matter what project I attempt to deploy and debug. The VS Extension will eventually stop working. BUT, smaller projects have a much greater chance of deploying over and over successfully.
  Large projects (any large project, it does not matter) will much more quickly cause the VS Extension to become confused.

• The faster the PC, the quicker is gets confused and gives up.
  I have a much, much slower machine at another location. The TinyCLR VS Extension works for hours before getting confused and requiring a reboot.

• When using my main desktop machine (blindingly fast PC), the VS Extension works for 5 to 20 minutes before it deteriorates to the point that it no longer works.

• Sometimes the TinyCLR VS Extension fails quickly, sometimes it starts giving odd errors and slowly deteriorates to eventually stop working.

My educated guess : the TinyCLR VS Extension and/or USB driver does not recover well from ANY USB hiccup or error. At that point, it’s internal state is corrupt and possibly unrecoverable.

---

Hope this information helps you to locate the problems. If I can assist further, just let me know.

We are working hard to get this application to the point that we can create a few test boards. We are already behind schedule. At this point, we should be running the 2000 unit trial that our customer has ALREADY committed to. Phase I rollout of 75,000 units is slated for this summer … I don’t think we will make that deadline.

I am available today and tomorrow (May 9 &10), but am leaving for Europe on Wednesday evening for about 5-6 weeks with limited email and Internet access during this time.

Once again … thanks for your assistance !

– Don

[Dat_Tran]

On different computer it work just fine?