Community

Windows Meadow F7 COM Port Connection Failure

I’m just getting started with the F7 on Windows and I’m attempting to:

meadow flash os

I understand the default COM port is “4” and can confirm this is set in clisettings.json.

When flashing the OS I get an error message “Failed to connect to Meadow on COM3”.

I’ve also tried specifying the serial port directly via:

meadow flash os -s 4

…but it still appears to connect on COM3 and fails.

Could this be an issue with the CLI or am I missing something obvious?

Try using meadow flash os -s com4

After cloning the Meadow.CLI git repo and debugging locally I found that the CLI fetches a list of COM ports from my machine, iterates them, and attempts to connect to each in the order they are received. It starts with COM3, the first in that list, and attempts to connect despite the fact that I specify COM4 as the serial port to use.

In my case the connection to COM3 exceeds 60 seconds and the CLI throws an exception.

It’s unclear if this is a bug in the CLI or an issue with my machine.

I will continue to investigate and will submit an issue in GitHub if appropriate.

For the benefit of others I’ll update this topic when I know more. Thanks @wlathbury

1 Like

I am keeping an eye on this as it may be related to my issue at Meadow OS Flash Failure - #3 by treygourley

As of right now I am getting errors like:

Connecting to Meadow on COM3
An error occurred while attempting to create Meadow
System.IO.FileNotFoundException: Could not find file 'COM3'.
File name: 'COM3'
   at System.IO.Ports.SerialStream..

The only difference for me is that my Meadow is on COM3.

Wow, You are willing to put a lot more effort into this than I am. I am seeing the same behavior, I am able to flash the OS on COM4, and then times out after a minute when it tries to connect to COM3.

In my case, I just disconnected and re-connected the Meadow and was able to deploy my application. It took me several readings of Jorge’s blog post to get my csproj file to a point where my app would compile.

TLS throws an error that my version of mono is out of sync, but if I flip everything from HTTPS to HTTP I am able to communicate with my web api, so I am currently running down the mono rabbit hole.

good luck,
Woody

Can you please raise that as an issue in the CLI repository as the expected behaviour should be to use the specified COM port.

Regards,
Mark

@andy.mehalick Not sure this will help you, but I was able to get my Meadow to update and get the HelloWorld app up-and-running. For me what seemed to dislodge whatever was going on was running the meadow download os command. After that my Meadow started communicating on COM4 (no idea why) and I had to run a few other commands and that got everything up-to-date that I could deploy the app from Visual Studio.

NOTE: I did have to manually download the latest dfu-util and replace the executables on my machine. A helpful command to in the command line to know where to drop those files is where dfu-util and it will return the directory you need.

Here is the order of commands I did that lead to the Meadow working for me:

meadow download os
meadow device info -s COM4
meadow flash os -s COM4
meadow mono state
meadow mono update rt
meadow flash esp

Hope this helps you.

Here is the link to the first post where things started working for me:

With the new CLI, running flash os will handle all of the updates automatically. Running mono update rt and flash esp are unnecessary.

The name of the port in this case is COM4, not just 4.

The CLI will attempt to use the port specified on the command line before falling back to searching available COM ports for the right Meadow. This algorithm isn’t perfect, and some systems may have trouble with the CLI opening COM ports that aren’t a Meadow. We’re working on improving this algorithm in future releases.