Any plan of improving Visual Studio Extension?

dcyonce · May 8, 2023, 7:19pm

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

Mike · May 8, 2023, 9:42pm

Dat_Tran · May 9, 2023, 1:47pm

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.

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 · May 9, 2023, 2:01pm

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 · May 9, 2023, 3:19pm

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 · May 9, 2023, 3:49pm

On different computer it work just fine?

dcyonce · May 9, 2023, 4:02pm

On ANY computer TinyCLR VS Extension works just fine … for a short while.

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.

Mike · May 9, 2023, 8:14pm

It would be interesting to see what would happen if you ran the TinyClr development environment in a virtual machine. It would provide an extra layer of USB handling.

I used to run GHI stuff in virtual machines on an Intel Mac. I have not tried it recently.

dcyonce · May 9, 2023, 8:32pm

It would be interesting to see what would happen if you ran the TinyClr development environment in a virtual machine. It would provide an extra layer of USB handling.

Hmm …
Interesting idea. I’ll have to try it.

I wonder if GHI has a virtual device I could try ??

skeller · May 9, 2023, 8:43pm

I run my TinyCLR development in a VMWare virtual machine using Wmware Workstation Pro. So far I have had no issues. I am running on Win10 for the main OS and the VM is also Win10. I have no idea if it would work on a MAC.
I create a VM for each major project I am working on. In my opinion, it makes it easier to keep things straight, especially if there are different TinyCLR firmware versions for different projects.

Brett · May 9, 2023, 9:54pm

I don’t want to tell you how to suck eggs, but a number of times here Dat has asked for a repro project. If you can’t give him one, or repro your long list of steps you took in a simple project, then you’re not getting any closer to debugging it. Logs are great, but just not the only source of debugging info.

Dat_Tran · May 10, 2023, 12:56pm

this is not really large projects. In simple project, can you add some resource, like a bitmap file, that will be easy to get over that size?

dcyonce · May 10, 2023, 2:15pm

Dat Tran,
I’m sorry. I don’t follow what it is you want me to test?

Are you wanting me to create a new simple project with a large bitmap to test the functionality of TinyCLR VS Extension???

Thanks for your help,
Don

Dat_Tran · May 10, 2023, 2:47pm

Hi, yes, if you can send us a project that we can reproduce easily, it would be good for us.

To make larger size, you can add any resource, binary, text, bitmap or whatever, this will make the size larger easily.

DimitriDimitriou · May 18, 2023, 10:47am

I have also found that if I run two projects in visual studio or two instances of Visual studio I can only connect to one device. Would be nice to debug multiple devices.

Dave_McLaughlin · May 19, 2023, 1:18pm

You can. You need to use TinyCLRConfig to give them a unique name and then you can select it in the DEBUG tab of Visual Studio. I’ve done this with 3 SITcore boards in the past.

DimitriDimitriou · May 19, 2023, 2:20pm

It’s the little things that help the most, perfect thanks for the bit knowledge