G120 USB Connection failed. Windows updated usb-drivers?

TinyCLR OS
1

All of a sudden, since maybe a couple of weeks, USB Connection to G120 devices have started to become unstable.
After a complete wipe (from booting in bootloader v1) and reset of the unit I can upload a new app, either using TinyCLR Config or with my own tool using GHIElectronics.TinyCLR.Debugger.Management
Sometimes I can do it another time, but usually it only works once, then the only way to deploy the app (or debug) is to completely erase the unit again.
Error: (which I interpet as the USB port being unresponsive, even though it is detected)
GHIElectronics.TinyCLR.Debugger.Management.MFDeviceNoResponseException
HResult=0x80131500
Source=GHIElectronics.TinyCLR.Debugger
StackTrace:
at GHIElectronics.TinyCLR.Debugger.Management.MFDeploy.InitializePorts(MFPortDefinition portDefinitionMain, MFPortDefinition portDefinitionTinyBooter)
at GHIElectronics.TinyCLR.Debugger.Management.MFDeploy.Connect(MFPortDefinition portDefinition)

I have tried with many units using G120 chips, and I have tried using 5 different PCs, and they are all the same. TinyCLR Config (or my own tools) crashes on the second or third attempt when I try flash a new app on the unit and then it is “bricked”, and can’t connect anymore.
What’s interesting is that nothing has changed here other that automatic updates to windows.

Is this a known issue? In that case, what’s the solution?

2

Maybe a Windows update has caused this!

Do you have a sitcore device and can see if you have any issues with TinyCLR v2?

3

we need to know what OS, window 10?
And TinyCLR Config 1.0, or FEZ Config?

Do you mean Firmware + App or Application only?

4

does this sound like the program is going into a tight loop right after starting?

5

and related to this line of questioning, are you developing the app on the G120, or has it been a stable codebase? If it’s in development then there’s a good chance of it being introduced with your changes

6

Dat_Tran:
We are using Windows 10 and TinyCLR Config 1.0
When I mean I can do another install I mean only the app. I install the firmware the first time after I have erased the unit and installed bootloader v2.

Mike:
It kinda does sound like it enters a loop. However, nothing in the code has changed. At least not in all the different tca-files I’ve tried. Some of the files are as old as 3 years.
However, they all come from the same origin, and some trash might have tagged along. With that in mind I installed a fresh “hello world”-app on it, and it works like a charm!

This means two things: First there is obviously something in my code that hangs the unit. I will spend the day trying to narrow it down, merging my hello world with our real app.
Secondly: I’ve been working with this project for five years and we have never had this problem before. As I said. I have tried installing old versions of the app, and they all freeze up and get semi-bricked. Hundreds of customers are using this, and many of those have had their applications updated with newer versions, and never have this happened. And now it happens on all units everywhere.

I’ll report back when I find what it is in my code that causes it.
I’ll also check if it happens on our sitcore prototype.

7

I found the error, and its not a loop.

During startup after initializing CAN, I send a message on the CAN-bus.
If the CAN-bus is completely unterminated at this time (I.E. the cables are unplugged), this happens. It bricks the unit.
Our units have several connections for CAN, and it is possible that over the years, and during development, we either have always had at least one end of the bus terminated, or we just havn’t tried to overwrite the app more than once.

8

So now the problem is this:

How do I check if the bus is heavy or off? The error callback only triggers when I try to use the bus, and then it’s too late.

9

Similar problems occur on the sitcore-unit. I also have to erase and reinstall it I use the CAN-bus without proper termination. In this case it crashes even with half termination.

10

Please try it again with sitcore but with a small program with CAN only and give us steps needed to reproduce the issue on our end.

Make sure to use the latest version of TinyCLR 2.1 please

11

Can you please provide a simple code, please?

Send from “the crash board” or send to “the crash board”? More detail will help us easier to see the problem, hate to say “could not reproduce” :)).

12

I accidentally destroyed one of our sitcore prototype units, so I havn’n been able to test this code on that one yet. I have only tested it on the sitcore development board, but it seems like the CAN-port is already terminated on that one, and won’t reproduce the error.
Since I don’t have any cable attached to the unit, I of course refer to it sending messages, not receiving them.
Here is the entire code I used on the G120 (TinyCLR 1.0).

using GHIElectronics.TinyCLR.Devices.Can;
using GHIElectronics.TinyCLR.Pins;
using System.Diagnostics;
using System.Threading;

namespace OQLSTLE
{
class Program
{
public static CanController CAN1 = CanController.FromName(G120.CanBus.Can1);

    public static void Main()
    {
        var propagation = 1; var phase1 = 13; var phase2 = 2; var baudratePrescaler = 15; var synchronizationJumpWidth = 1; var useMultiBitSampling = false;
        CAN1.SetBitTiming(new CanBitTiming(propagation, phase1, phase2, baudratePrescaler, synchronizationJumpWidth, useMultiBitSampling));
        CAN1.ReadBufferSize = 1024;
        CAN1.Enable();

        //CAN1.MessageReceived += CAN1_MessageAvailable;
        CAN1.ErrorReceived += CAN1_ErrorReceived;

        var msg = new CanMessage
        {
            ArbitrationId = 0x18EAFFD0,
            Length = 3
        };
        msg.Data[0] = 0x00;
        msg.Data[1] = 0xEE;
        msg.Data[2] = 0x00;
        msg.IsRemoteTransmissionRequest = false;
        msg.IsExtendedId = true;
        
        CAN1.WriteMessage(msg);
        Thread.Sleep(-1);
    }


    private static void CAN1_ErrorReceived(CanController sender, ErrorReceivedEventArgs e)
    {
        Debug.WriteLine("CAN1 Error : " + e.Error.ToString());
    }
}

}

13

We couldn’t reproduce the issue on our 20260 Dev or 20260 Portal. These give us error event as well.

14

Ok, and have you made sure that those don’t have termination on the CAN port? The 20260 Dev board I have is terminated on the PCB.

15

Isn’t there a jump that we can insert/remove easily? Is there another “terminated” on 20260Dev?

Anyway, no matter this jumper is set or not, error events raised as well. No crash found.
Also tested on Portal because there is no CAN module to see if crash, error events also raised.
Tested on 2.1.0.6200 release.

We haven’t tested on G120 yet, it is time to upgrade to SITCore. But we will check on G120 when have time.

16

Not sure if there is a jumper that can be set for terminating the can bus. Full termination should be 120 ohm, and when this is the case there is no crash either. If you have tried to replicate my errors with 60 or 120 ohm termination you are missing the point.
We are in the process of upgrading, but lots of customers still have the G120, and we sell many still, so we still need to be able to support these.

17

I am a bit confused here. Is this a new design with G120? And why not use netmf for your G120. TinyCLR 1.0 is good for experimenting with TinyCLR but it has many limitations and bugs that were resolved in TinyCLR 2.x