FezFlea - loosing debugger

I’ve been trying to debug this code to no avail. The debugger terminates without doing a thing.
The message in the output says:

Loading Deployment Assemblies.

Attaching deployed file.

Assembly: mscorlib (2.2.0.5000) Attaching deployed file.

Assembly: GHIElectronics.TinyCLR.Devices.Uart (2.2.0.5000) Resolving.

Link failure: some assembly references cannot be resolved!!

using GHIElectronics.TinyCLR.Devices.Uart;
using GHIElectronics.TinyCLR.Pins;

namespace TinyCLRApplication1
{
    internal class Program
    {
        static void Main()
        {
            var txBuffer = new byte[] { 0x41, 0x42, 0x43, 0x44, 0x45, 0x46 }; //A, B, C, D, E, F
            var rxBuffer = new byte[txBuffer.Length];

            var myUart = UartController.FromName(SC13048.UartPort.Uart1);

            
        }

    }
}

I have just finished using a flea uart without any issues.

I would first reload the firmware.

.5100 is the latest version. NuGet update?

There is no 5100 nuget package though.

EDIT: It keeps saying
Assembly: GHIElectronics.TinyCLR.Devices.Uart (2.2.0.5000) needs assembly ‘GHIElectronics.TinyCLR.Native’ (2.2.0.5000)

No matter which firmware and nuget combo, I downgrade to do nothing. I still get the same error.
Also, the Flea came with version 2.2.0.6100 firmware which isn’t even out yet.

Well, something about this UART thing is fundamentally broken. I even downloaded all the code from GitHub - ghi-electronics/TinyCLR-Libraries: Official Libraries supporting TinyCLR OS, compiled it, and referenced the relevant libs, and it still doesn’t work.
“Cannot find any entrypoint!”

Try adding an infinite wait at end of program so it does not exit.

Can’t see why that would help but worth a try.

It still can’t find the entry point. I’ll try to copy all the code from the libraries into my single application and try again.

Nothing is working. Once I add UART, it doesn’t run or attach, and I get the errors mentioned above.

SitCore may be broken; as it would be once, I finally get around to using it. Story of my life.

What happens with a null program?

An empty program works and debugs just fine.

Have you tried a new project?

I have tried a file new project. Same results.

I ordered a flea from Amazon. It will arrive Tuesday.

If you have not found the issue, you can send me a failing project and I will see what happens in my environment.

Do you think it could be the hardware? That would sucketh.

Three alternatives:

  1. Hardware
  2. Software
  3. Thee

I’ve been digging around in the code base trying to implement the functionality of the UART directly in the program. Here is something fishy that I noticed. Whenever I declare this EventHandler, the program throws, “Link failure: some assembly references cannot be resolved!!” error:

using GHIElectronics.TinyCLR.Devices.Uart;

namespace TinyCLRApplication1
{
    internal class Program
    {
        static void Main()
        {
            ClearToSendChangedEventHandler clearToSendChangedCallbacks;
        }
    }
}

I am seeing something very similar with the FEZ Pico. I purchased two new Picos from Mouser and updated them to the latest firmware (2.2.0.5100) with no issues. They are both Rev D boards. When I try to download and run some existing Pico code that uses I2C I get the error:

Link failure: some assembly references cannot be resolved!!

Assembly: GHIElectronics.TinyCLR.Devices.I2c (2.2.0.5000) needs assembly ‘GHIElectronics.TinyCLR.Devices.Gpio’ (2.2.0.5000)

Assembly: GHIElectronics.TinyCLR.Devices.I2c (2.2.0.5000) needs assembly ‘GHIElectronics.TinyCLR.Native’ (2.2.0.5000)

Assembly: xxxx (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.I2c’ (2.2.0.5000)

Assembly: yyyy (1.0.0.0) needs assembly ‘GHIElectronics.TinyCLR.Devices.I2c’ (2.2.0.5000)

Error: a3000000

Waiting for debug commands…

If I replace the FEZ Pico with the original board with the same firmware and Rev D everything works as expected.

From memory the 2.2.0.5100 firmware was a minor fix and the libraries didn’t roll from 2.2.0.5000. This has worked previously.

I have re-compiled the code and re-flashed the firmware on the new boards with no change. I am reluctant, at the moment, to re-flash the old board and lose a working version.

I also purchased a new FEZ Feather and updated it to the latest firmware but I have not tested it with an existing application.

I hope this additional information helps.
Thanks.

RESOLVED:
Using TinyCLR Config I did an “Erase All” and loaded the 2.2.0.5000 firmware.
Using Visual Studio I then compiled and downloaded the application - all ran as expected.
Using TinyCLR Config I updated the firmware to 2.2.0.5100.
Using Visual Studio I then compiled and downloaded the application - all ran as expected.

Note: I didn’t change the code or Nuget library versions.

I do not know if you can leave out the compile and download steps and just start with the 2.2.0.5000 firmware and then update to 2.2.0.5100. I won’t have a chance to have a good look until the weekend.

Hope that this helps.
Thanks.

1 Like

Erase All. This works for me as well. This is very weird.

Okies then, when updating the firmware, first “Erase All”!

USB CDC Now works! I have redirected the debugger over com port.

Thanks, Everyone!

@Mike, I guess it was a 2.) Software problem.

Did you find t3?