Main Site Documentation

G80/TinyCLR freezes on Erasing Sector 1


G80, flashed with with the latest TinyCLR build.

After I flash the code below, it works the first time. However, whenever I try to deploy or debug again, I have to fully erase the chip with the bootloader and reload the TinyCLR and then reload the program and again vicious cycle.

using System;
using System.Collections;
using System.Diagnostics;
using System.Text;
using System.Threading;
using GHIElectronics.TinyCLR.Devices.Can;
using GHIElectronics.TinyCLR.Devices.Can.Provider;
using GHIElectronics.TinyCLR.Devices.Gpio;
using GHIElectronics.TinyCLR.Pins;

namespace TestTinyCLR
	class Program
		static void Main()

			GpioPin led = GpioController.GetDefault().OpenPin(G80.GpioPin.PE14);

			Thread ledThread = new Thread(new ThreadStart(NewThreadMethod));

			var can = CanController.FromId(G80.CanBus.Can1);

			// Setup timing here
			int prop = 9;
			int phase1 = 4;
			int phase2 = 3;
			int brp = 1;
			int sjw = 1;
			bool useMultiBitSampling = false;

			can.SetBitTiming(new CanBitTiming(prop, phase1, phase2, brp, sjw, useMultiBitSampling));

			var message = new CanMessage(0xFF, new byte[] { 0xAA });
			Debug.WriteLine("Message Sent");

			can.ErrorReceived += CanController_ErrorReceived;

			while (true)

		private static void CanController_ErrorReceived(CanController sender, ErrorReceivedEventArgs e)
			Debug.WriteLine("Error " + e.ToString());

		static void NewThreadMethod()
			GpioPin led2 = GpioController.GetDefault().OpenPin(STM32F4.GpioPin.PE13);

			while (true)


Same behaviour here.
If I remove all CAN code, it runs fine so it’s probably related to CAN and deploy.


Did we mess up CAN? :open_mouth:


this is a known issue 0.9.0:


I seen that the issue was fixed with #201

I got latest and rebuilt from source.

The issue where it freezes on Erasing sector 1 is resolved, however, a new bug has been introduced.

After VS deploys for the second time, it completes deployment. However, the device hangs and VS cannot connect to debug. (See below)

Also, attempting to erase the app from TinyCLR Config fails, as it freezes until I disconnect the board.

Is this the proper channel to report these bugs/issues?

Looking for a device on transport 'USB'.
Found device port 'USB' with ID '76e9b560-cc31-4993-a64f-b419dde268b8' for transport 'Usb'.
Starting device deployment.
Attempting to connect to device 'USB:G80': iteration 0.
Opening port '\\?\usb#vid_1b9f&pid_5009#7&322c59c1&0&1#{c13bcfe9-5e84-4187-9baa-45597ffcbb6f}'.
Attaching debugger engine.
Debugger engine attached.
Querying device assemblies.
Found assemblies:
	- TestTinyCLR v1.0.0.0.
	- mscorlib v0.9.0.0.
	- GHIElectronics.TinyCLR.Devices v0.9.0.0.
Generating device specific assemblies.
Deploying assemblies:
	- TestTinyCLR v1.0.0.0 with size 1,572 bytes at 'C:\Users\zeroa\Documents\Visual Studio 2017\Projects\TestTinyCLR\TestTinyCLR\bin\Debug\pe\'.
	- mscorlib v0.9.0.0 with size 77,204 bytes at 'C:\Users\zeroa\Documents\Visual Studio 2017\Projects\TestTinyCLR\TestTinyCLR\bin\Debug\pe\'.
	- GHIElectronics.TinyCLR.Devices v0.9.0.0 with size 50,324 bytes at 'C:\Users\zeroa\Documents\Visual Studio 2017\Projects\TestTinyCLR\TestTinyCLR\bin\Debug\pe\'.
Total deployment size is 129,100 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.'.


The bug mentioned above is also present in the latest build of G120 firmware. :frowning:

VS Just freezes and sits there


Tell us exactly log commit id then we will try.


It is the latest build from GitHub. I downloaded and built 0c11b65 today, and G80 still crashes on second deploy during debugging attachment and G120 wont recognize as a TinyCLR device at all now :confused:



I believe something went wrong with your project. You shouldn’t see any issue on G120.

Latest build may require latest core library, it could be your problem.

Try to see the fix and apply it locally.


As I see 0x0C11B65 it requires to change something with RTC so you should not use it.

Try to use the log:

“Merge pull request #216 from ghi-electronics/201_CanFreeGetMsgAfterSetBufferSize” created on 3/5/2018.