FezFlea - loosing debugger

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?

Did I find the issue? Yes, I had to Erase All in TinyClr Config tool

I meant where did you find the MOD pin on pad T3?

Oh no. I didn’t find that pin. I tried the only two things on the board that might be it, but the Flea didn’t show up when I plugged it in. I managed to change the debug port using the Config tool.

Hi, sorry for missing this post.

I guess here is what you need, the yellow one is TP3

1 Like

So that pin connects to GND to enable Serial debug on port 1?

Yes, it should be low to switch to UART mode

Just for reference, what is the other one below the LDR switch for? I assume this is NRST as per the schematic?

yes, that is reset line

Having the very same problem with a PICO and a Feather.
I’ve found that the TinyCLR Extension and USB driver gets confused after a while.

Rebooting the PC makes it start working again … for a while. And then I need to reboot again.
Or … uninstall the Flea’s USB Device (SC13048) and let it reinstall.

Problem seems to be with the TinyCLR Visual Studio Extension and SitCore USB Driver.
It THINKS a previous deployment was successful, but it wasn’t. So, when the debugger starts, it errors out because its missing some assemblies. Erasing the Flea/PICO/Feather restarts the deployment, and then it may work (or may not !).

– Don

it could be the extension, also could be your code.

When we develop a project, we usually add a loop in main, waitng for press a button before doing anything next.

void DoRun() {
// project start here
}

void Main() {


while ( button.Pressed() == false)
     thread.sleep(10)

// start project
DoRun();

}

button.Press : you can replace by gpio.Read…

Dat Tran,
My code NEVER gets a chance to execute. The Visual Studio Extension NEVER loads my code.

See the logs at Any plan of improving Visual Studio Extension? - TinyCLR OS - GHI Electronics’ Forums
Don