Meadow Command-Line-Interface for interacting with Meadow and Meadow.Cloud via terminal. Also includes `Meadow.CLI.Core`, which can be used programmatically from an app as a library.
License: Apache License 2.0
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Can we wrap and catch exceptions to cleanup the end user experience when an exception is thrown?
Using Windows 7 x64 with usbser.sys 6.1.7601.17514(win7sp1_rtm.101119-1850) driver I faced a problem with device reconnection after its reset.
The System.IO.FileNotFoundException is thrown on attempt to close the serial port.
CLI output on --MonoEnable cmd
Opening port 'COM32'
Data: Mono enabled, will run app.exe
App: Initialize hardware...
ID: Meadow by Wilderness Labs, Model: F7Micro, MeadowOS Version: 0.4.2 (Dec 8 2020 10:09:54),
Processor: STM32F777IIK6, Processor Id: 37-00-3d-00-0d-51-38-32-37-35-36-30,
Serial Number: 307335783238, CoProcessor: ESP32, CoProcessor OS Version: 0.4.2.0
App: Cycle colors...
Data: Mono has been enabled. Restarting F7 Micro
Host Serial Reconnect
Exception: System.IO.FileNotFoundException: Unable to find the specified file.
at System.IO.Ports.SerialStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at System.IO.Ports.SerialPort.Dispose(Boolean disposing)
at System.ComponentModel.Component.Dispose()
at System.IO.Ports.SerialPort.Close()
at MeadowCLI.DeviceManagement.MeadowSerialDevice.Initialize(Boolean listen) i
n C:\Users\Dmitriev\Desktop\C#Projects\Meadow.CLI\Meadow.CLI.Core\DeviceManageme
nt\MeadowSerialDevice.cs:line 87
at MeadowCLI.DeviceManagement.MeadowSerialDevice.AttemptToReconnectToMeadow()
in C:\Users\Dmitriev\Desktop\C#Projects\Meadow.CLI\Meadow.CLI.Core\DeviceManage
ment\MeadowSerialDevice.cs:line 429
at MeadowCLI.DeviceManagement.MeadowSerialDevice.DataReceived(Object sender,
MeadowMessageEventArgs args) in C:\Users\Dmitriev\Desktop\C#Projects\Meadow.CLI\
Meadow.CLI.Core\DeviceManagement\MeadowSerialDevice.cs:line 365
at MeadowCLI.Hcom.MeadowSerialDataProcessor.ParseAndProcessReceivedPacket(Byt
e[] receivedMsg, Int32 receivedMsgLen) in C:\Users\Dmitriev\Desktop\C#Projects\M
eadow.CLI\Meadow.CLI.Core\Internals\MeadowComms\MeadowSerialDataProcessor.cs:lin
e 323
Exception communicating with Meadow:
Exception of type 'MeadowCLI.DeviceManagement.MeadowDeviceManagerException' was thrown.
Add the ability for the CLI to abort a file transfer if there is a problem writing to the file system.
There are two different behaviours if there is a problem writing a file to the flash file system:
1 - 0.5.3 - HCOM locks waiting for the file to be written to storage. This is a problem in stm32_qspi.c code.
2 - Post 0.5.3 - HCOM has been modified to send an error message back to the CLI to indicate there is a problem.
We cannot do anything about 1 as this code is out in the wild. But we can do something about 2.
HCOM has been modified to send two error messages to CLI:
The two messages will be sent for every packet so it will get chatty if we do not abort the transfer.
Not sure what ending the file transfer early will do :)
Latest OS build is required for this, build information will be added when available.
Note that will need to put a number of files on the board to get close to filling the flash before testing. I put a simple application (plus associated DLLS) on the board then then added 6 copies of mscorlib (copied to some dummy files). I then tried three consecutive writes of mscorlib to the board under its rel name.
We used to be able to specify the ESP binary files and the flash address when writing the bootloader, partition table and firmware.
meadow flash esp --help does not show these options and meadow flash os --help does not seem to allow you to do this either.
Justification for the request: This will allow the internal distribution of beta ESP firmware files.
from build pipeline - can probably remove
I'm using the CLI with VS Code and I get the following exception when detaching VS Code from the debugger:
Unhandled exception. Error receiving data from Visual Studio
System.AggregateException: One or more errors occurred. (Timeout while writing to serial port)
---> System.TimeoutException: Timeout while writing to serial port
at Meadow.CLI.Core.Devices.MeadowLocalDevice.<>c.<EncodeAndSendPacket>b__57_0() in D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:line 277
at System.Threading.CancellationToken.<>c.<.cctor>b__26_0(Object obj)
at System.Threading.CancellationTokenSource.CallbackNode.<>c.<ExecuteCallback>b__9_0(Object s)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.CancellationTokenSource.CallbackNode.ExecuteCallback()
at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
--- End of inner exception stack trace ---
at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
at System.Threading.CancellationTokenSource.NotifyCancellation(Boolean throwOnFirstException)
at System.Threading.CancellationTokenSource.<>c.<.cctor>b__56_0(Object obj)
at System.Threading.TimerQueueTimer.CallCallback(Boolean isThreadPool)
at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
at System.Threading.TimerQueue.FireNextTimers()
[1] 34182 abort meadow debug
Steps to reproduce:
meadow debug from a command lineThe CLI should generate the above exception.
FYI - launch.json I'm using looks like this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Attach",
"type": "mono",
"request": "attach",
"address": "127.0.0.1",
"port": 4024
}
]
}
this command isn't supported
The command:
meadow file write -f App.exe
generates an exception:
Writing App.exe as App.exe to partition 0
ERROR
System.IO.FileNotFoundException: Cannot find source file
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WriteFileAsync(String filename, String path, TimeSpan timeout, CancellationToken cancellationToken) in /D:\a\1\s\Meadow.CLI.Core\Devices\MeadowLocalDeviceFileManager.cs:119
at Meadow.CLI.Commands.Files.WritesFileCommand.ExecuteAsync(IConsole console) in /D:\a\1\s\Meadow.CLI\Commands\Files\WriteFileCommand.cs:78
at CliFx.CliApplication.RunAsync(ApplicationSchema applicationSchema, CommandInput commandInput) in /home/runner/work/CliFx/CliFx/CliFx/CliApplication.cs:147
at CliFx.CliApplication.RunAsync(IReadOnlyList`1 commandLineArguments, IReadOnlyDictionary`2 environmentVariables) in /home/runner/work/CliFx/CliFx/CliFx/CliApplication.cs:191
Done!
On my Lenovo Carbon X1 machine I have a serial port named Intel(R) Active Management Technology - SOL (COM3)
and when the code in GetMeadowSerialPortsForWindows executes the powershell script to get the serial ports, it outputs this data:
Port: USB Serial Device (COM5), Name: Meadow F7 Micro, DeviceID: USB\VID_2E6A&PID_0001\335C336B3036
Port: Intel(R) Active Management Technology - SOL (COM3), Name: PCI Serial Port, DeviceID: PCI\VEN_8086&DEV_A0E3&SUBSYS_22D517AA&REV_20\3&11583659&1&B3
The problem is that Intel(R) gets detected as a serial port, and then fails to open.
I'm testing on a slow PC and slow connection - it took 5-10s to download but it wasn't obvious anything was happening ... a simple "Meadow OS download started .... " would be great
meadow install dfu-util in a normal command prompt on Windows shows a success message but doesn't actually install. Should throw and error and prompt users to open prompt in admin mode.
that's the standard break/terminate command in macOS (not ctrl+z)
During b5.3 testing there appeared to be some inconsistency with the file loaded on to the board.
meadow flash os -o Meadow.OS.bin -r Meadow.OS.Runtime.bin
seemed to write the RT from the directory the command was being executed from but the OS from the download cache.
The final board had 0.5.2.0 of the OS deployed with 0.5.3.0 of the RT. This is consistent with the file in the cache being 0.5.2 and the files in the local directory being 0.5.3.
I am experiencing issues while trying to update ESP32 coprocessor using CLI.
Version: Meadow.CLI 0.12.3
According to console, step where Mono runtime is disabled went well.
Same goes for runtime update.
But, when I try to update coprocessor I get following error.
Perhaps I am doing something wrong?
So I have a local copy of the firmware deployed with version number 0.6.3.8 and meadow mono disable generates this exception:
Error checking for updates
System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()
at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
at Meadow.CLI.Core.DownloadManager.CheckForUpdatesAsync() in D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\DownloadManager.cs:line 251
Connecting to Meadow on /dev/tty.usbmodem3354336F30361
Internal OS version so unlikely to impact customers.
Can we display the CLI version after the help list?
And for this release we need to bump to 0.14.3
When running the CLI with -s COMx and it calls FindMeadowBySerialNumber then this parameter is ignored. I'm not 100% sure what the correct fix is, but I noticed this when the CLI tried to open a port named "R" on my machine during the "Fallback to brute force searching" portion in this method. It should only try the specified port IMO.
Despite huge autoconect improvements in the CLI, I still typically run meadow with the parameter -s /dev/ttyACM* on Linux to make it reliable. Here is a typical scenario for me where Meadow is found and then "lost":
$ meadow mono disable
Connecting to Meadow on /dev/ttyACM1
Meadow StdInfo: Mono is enabled
Meadow StdInfo: Mono has been disabled. Restarting Meadow
Connecting to Meadow on /dev/ttyACM1
Connecting to Meadow on /dev/ttyACM2
Meadow StdInfo: Mono is disabled.
Meadow StdInfo: Mono is disabled
Mono Disabled Successfully
Done!
$ meadow mono enable
Connecting to Meadow on /dev/ttyACM1
Unable to find Meadow.
Notice that the mono disable invocation searched and found the new path for the Meadow (/dev/ttyACM2) when ACM1 didn't work, but mono enable not only went back to looking for it on ACM1, it did not fall back to searching after that was not found.
In general I am afraid that using any previously saved Meadow path (without falling back to full search) will be unreliable (what if I closed my laptop between meadow invocations; even button resets change the number in Linux, etc.)
Posted to the Slack support channel on April 3rd, 2022 with no replies to date. Reposting as an issue now.
meadow use port [comXX] and meadow [ command] -s [comxx] always fails with error message:
"Selected serial port [comXX] does not exist. Use 'meadow list ports' to view available options and 'meadow use port' to select a valid port"
meadow list ports correctly lists the com ports
The following remedies have been tried:
This problem is the same on all 3 meadow F7v1s that I have
dfu-util correctly lists the device
Found DFU: [0483:df11] ver=2200, devnum=18, cfg=1, intf=0, path="1-2.3", alt=3, name="@device Feature/0xFFFF0000/01004 e", serial="346438663536"
Found DFU: [0483:df11] ver=2200, devnum=18, cfg=1, intf=0, path="1-2.3", alt=2, name="@otp Memory /0x1FF0F000/01001Ke,01032 e", serial="346438663536"
Found DFU: [0483:df11] ver=2200, devnum=18, cfg=1, intf=0, path="1-2.3", alt=1, name="@option Bytes /0x1FFF0000/01032 e", serial="346438663536"
Found DFU: [0483:df11] ver=2200, devnum=18, cfg=1, intf=0, path="1-2.3", alt=0, name="@internal Flash /0x08000000/04032Kg,01128Kg,07*256Kg", serial="346438663536"
meadow flash os command gets to the point where it is to connect to the com port and then fails with an unhandled exception - System.TimeoutException: Timeout while writing to serial port
everything worked fine up till I CLI version v0.19.1
Currently: Updated Meadow to OS: 0.6.7.18 (Sep 13 2022 14:58:44) ESP: 0.6.7.18
Should probably match meadow device info
Firmware Versions - OS: 0.6.7.18 (Sep 13 2022 14:58:44) Mono: 0.6.7.18, Coprocessor: 0.6.7.18
And "Firmware Versions" doesn't sound quite right either .... maybe just "Meadow Versions" or "Meadow OS versions"
It looks like the file system is cleared but the following exception is generated:
Connecting to Meadow on /dev/tty.usbmodem3064358132381
Renewing file system on the Meadow.
ERROR
Meadow.CLI.Core.Exceptions.MeadowCommandException:
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WaitForResponseMessageAsync(Command command, CancellationToken cancellationToken, String caller) in /C:\Projects\Meadow.CLI\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:400
at Meadow.CLI.Core.Devices.MeadowLocalDevice.SendCommandAsync(Command command, CancellationToken cancellationToken, String caller) in /C:\Projects\Meadow.CLI\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:210
at Meadow.CLI.Commands.FileSystem.RenewFileSystemCommand.ExecuteAsync(IConsole console) in /C:\Projects\Meadow.CLI\Meadow.CLI\Commands\FileSystem\RenewFileSystemCommand.cs:25
at CliFx.CliApplication.RunAsync(ApplicationSchema applicationSchema, CommandInput commandInput) in /home/runner/work/CliFx/CliFx/CliFx/CliApplication.cs:147
at CliFx.CliApplication.RunAsync(IReadOnlyList`1 commandLineArguments, IReadOnlyDictionary`2 environmentVariables) in /home/runner/work/CliFx/CliFx/CliFx/CliApplication.cs:191
Done!
When OS version is set to an internal version then you can get the following error for a meadow app deploy request:
meadow app deploy -i -f App.dll ✔ 09:12:07
Connecting to Meadow on /dev/tty.usbmodem3067357532381
Download version file for release 0.6.0.8
ERROR
System.Net.Http.HttpRequestException: Response status code does not indicate success: 404 (Not Found).
So on the board I have version 0.6.0.8 and I am trying to perform an application deployment. Note that the flash is empty.
Trying to flash just the ESP with a version number fails with "meadow did not accept command".
Also , the API supports giving it a file but the CLI does now (and since it's really 3 files, how would that work?)
wonder if we should rethink this command ... rt -> runtime ?
not sure the mono part of the command is adding any value ....
To delete all files on the file system - useful for testing and easier than erasing the flash
Getting a problem with the CCM when trying to write files to the board. I get the following exception when writing to the board:
Connecting to Meadow on /dev/tty.usbmodem3360317434381
Writing App.dll as App.exe to partition 0
Starting File Transfer...
Meadow StdInfo: File 13% downloaded
Meadow StdInfo: File 21% downloaded
Meadow StdInfo: File 30% downloaded
Meadow StdInfo: File 43% downloaded
Meadow StdInfo: File 52% downloaded
Meadow StdInfo: File 60% downloaded
Meadow StdInfo: File 73% downloaded
Meadow StdInfo: File 82% downloaded
Meadow StdInfo: File 91% downloaded
Exception sending command to Meadow
RequestType: HCOM_MDOW_REQUEST_END_FILE_TRANSFER Timeout: 00:01:00 UserData: 1 ResponseType none CompletionMessageType: none ResponseHandler: False CompletionPredicate: True ResponsePredicate: True
Meadow.CLI.Core.Exceptions.MeadowCommandException: Command timeout waiting for response.
---> System.Threading.Tasks.TaskCanceledException: A task was canceled.
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WaitForResponseMessageAsync(Command command, CancellationToken cancellationToken, String caller) in D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:line 372
--- End of inner exception stack trace ---
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WaitForResponseMessageAsync(Command command, CancellationToken cancellationToken, String caller) in D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:line 378
at Meadow.CLI.Core.Devices.MeadowLocalDevice.SendCommandAsync(Command command, CancellationToken cancellationToken, String caller) in D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:line 209
at Meadow.CLI.Core.Devices.MeadowLocalDevice.SendTheEntireFile(FileCommand command, Boolean lastInSeries, CancellationToken cancellationToken) in D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:line 134
ERROR
Meadow.CLI.Core.Exceptions.MeadowCommandException: Command timeout waiting for response.
System.Threading.Tasks.TaskCanceledException: A task was canceled.
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WaitForResponseMessageAsync(Command command, CancellationToken cancellationToken, String caller) in /D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:372
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WaitForResponseMessageAsync(Command command, CancellationToken cancellationToken, String caller) in /D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:378
at Meadow.CLI.Core.Devices.MeadowLocalDevice.SendCommandAsync(Command command, CancellationToken cancellationToken, String caller) in /D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:209
at Meadow.CLI.Core.Devices.MeadowLocalDevice.SendTheEntireFile(FileCommand command, Boolean lastInSeries, CancellationToken cancellationToken) in /D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceComms.cs:134
at Meadow.CLI.Core.Devices.MeadowLocalDevice.WriteFileAsync(String sourceFileName, String destinationFileName, TimeSpan timeout, CancellationToken cancellationToken) in /D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI.Core\Devices\MeadowLocalDeviceFileManager.cs:134
at Meadow.CLI.Commands.Files.WritesFileCommand.ExecuteAsync(IConsole console) in /D:\a\Meadow.CLI\Meadow.CLI\main\Meadow.CLI\Commands\Files\WriteFileCommand.cs:78
at CliFx.CliApplication.RunAsync(ApplicationSchema applicationSchema, CommandInput commandInput) in /D:\a\CliFx\CliFx\CliFx\CliApplication.cs:147
at CliFx.CliApplication.RunAsync(IReadOnlyList`1 commandLineArguments, IReadOnlyDictionary`2 environmentVariables) in /D:\a\CliFx\CliFx\CliFx\CliApplication.cs:191
Done!
Connecting to Meadow on /dev/tty.usbmodem3360317434381
Unable to find Meadow.
I have a meadow.config.yaml deployed to the board with the following content:
Network:
Ethernet:
Default: true
IPAddress: 192.168.1.60
NetMask: 255.255.255.0
Gateway: 192.168.1.254
WiFi:
Default: false
GetNetworkTimeAtStartup: 1
NtpServers:
- 0.uk.pool.ntp.org
- 1.uk.pool.ntp.org
- 2.uk.pool.ntp.org
- 3.uk.pool.ntp.org
NtpRefreshPeriod: 3600
DnsServers:
- 1.1.1.1
Debug:
Uart1Use: trace
TraceLevel: 1
Note that the file looks to be written OK as I am seeing this when I turn on UART output from the STM32:
[ 0.287000] Ethernet is being initialized
[ 0.287000] (Note) Meadow 0.6.5.13 (Jul 5 2022@14:45:11) rebooted, H/W:CCMv2, Mono:Disabled, Trace level:0x7f, to:UART1 (ramlog)
[ 0.291000] (Warn) mono/hcom_mono_control.c@427-Mono is disabled.
[ 1.256000] ESP32 Coprocessor ready, firmware version 0.6.5.2
[ 2.361000] Ethernet active MAC:4a:5a:6a:09:98:08, IP:192.168.1.60
[ 5.363000] Link Status of PHY 1 is Up
[ 5.363000] Getting time from 0.uk.pool.ntp.org
[ 5.384000] INFO: '0.uk.pool.ntp.org' resolved to: 5.101.146.245
[ 5.409000] ToDo: Ethernet updated time, Mono needs to be notified
[ 39.110000] (Info) file/hcom_file_dnld_proc.c@183-Meadow downloading file (FileLen:11776, Crc:0xdfb36537, Name:App.exe)
[ 39.278000] (Note) End of file transfer
Steps:
meadow file write -f App.dll -t App.exeThe system should write the file and then lock, eventually timing out. The file being written does not have to be the App.dll, it can be the config file itself.
Resetting the board allows you to write files and disable the application etc.
The file write works OK if the default network interface is set to WiFi .
Because of the dirty string.Contains check in
This prevents flashing the board OS when running on a non-english computer OS.
No changes needed to CLI.Core
Looks like we can multitarget .NET 5 & 6
<TargetFrameworks>net5.0;net6.0</TargetFrameworks>
allow flashing of old release versions of the OS - good for testing now - important for end users after v1.0
When running the command meadow flash os with an outdated version of dfu-util the CLI shows an error/warning message with advice on how to update dfu-util. The message appears to recommend a command from a previous version of the CLI which may confuse new users:
❯ meadow flash os
Entering DFU Mode
Device in DFU Mode, flashing OS
Flashing OS with C:\Users\Andy\AppData\Local\WildernessLabs\Firmware\Meadow.OS.bin
dfu-util update required. To install, run in administrator mode: meadow --InstallDfuUtil
The CLI command meadow --InstallDfuUtil in v0.14.0 appears to be incorrect, I'm assuming it should be meadow install dfu-util.
If I'm correct I can submit a simple PR to update the message, I'd love to get involved in this project.
output says ESP23
executing meadow mono enable kills the connection to the board. It would be nice to have the option to keep the connection open so that console output can be captured / displayed.
meadow set developer has two uses for the -v flag.
meadow set developer --help
meadow v0.14.5
USAGE
meadow set developer [options]
DESCRIPTION
Set developer value
OPTIONS
-d|--developer The developer value to set. Valid values are 1 - 4 Default: "0".
-v|--value The value to apply to the developer value. Valid values are 0 to 4,294,967,295 Default: "0".
-s|--SerialPort Meadow COM port Default: "/dev/tty.usbmodem3354336F30361".
-v Log verbosity
-h|--help Shows help text.
Done!
System.ArgumentException: An item with the same key has already been added. Key: C:\projects\pekkah\meadow-libs\src\Verify.Wifi\bin\Debug\netstandard2.1\App.exe
at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
at Meadow.CLI.Core.Devices.MeadowLocalDevice.<>c__DisplayClass74_0.<<DeployAppAsync>g__AddFile|2>d.MoveNext() in D:\a\1\s\Meadow.CLI.Core\Devices\MeadowLocalDeviceFileManager.cs:577
at Meadow.CLI.Core.Devices.MeadowLocalDevice.DeployAppAsync(String applicationFilePath, String osVersion, Boolean includePdbs, CancellationToken cancellationToken) in D:\a\1\s\Meadow.CLI.Core\Devices\MeadowLocalDeviceFileManager.cs:598
at Meadow.CLI.Core.Devices.MeadowDeviceHelper.DeployAppAsync(String fileName, Boolean includePdbs, CancellationToken cancellationToken) in D:\a\1\s\Meadow.CLI.Core\Devices\MeadowDeviceHelper.cs:270
at Meadow.CLI.Commands.App.DeployAppCommand.ExecuteAsync(IConsole console) in D:\a\1\s\Meadow.CLI\Commands\App\DeployAppCommand.cs:40
at CliFx.CliApplication.RunAsync(ApplicationSchema applicationSchema, CommandInput commandInput) in \home\runner\work\CliFx\CliFx\CliFx\CliApplication.cs:147
at CliFx.CliApplication.RunAsync(IReadOnlyList`1 commandLineArguments, IReadOnlyDictionary`2 environmentVariables) in \home\runner\work\CliFx\CliFx\CliFx\CliApplication.cs:191
It seems that the file App.exe is on both binaries list and dependencies list at lines 590 and 596 of MeadowLocalDeviceFileManager. Then app tries to add it twice to the files dictionary where the error above gets thrown.
HCOM is reporting that this option is not supported.
Message from HCOM: (Error) comms/hcom_host_route.c@404-Received unsupported request type:0x0103
The above message can be seen in trace output.
I'm not sure if this is how it is designed to work but meadow mono enable does not reset the board if mono is already enabled.
If this is as designed can we please have an option for mono enable to force a reset, say -r.
Background, I am deploying applications manually through the command line and keep having to remember to disable mono before re-enabling it in order for the newly deployed application to run.
Just received the following message when upgrading a board:
Meadow StdInfo: Mono will not start. Mono version is not available (Meadow.OS version 0.6.2.0).
Your OS version is older than 0.6.1.0. A bulk flash erase is highly recommended.
Proceed? (Y/N) Press Y to erase flash, N to continue install without erasing
Upgrading to 0.6.3.0 using CLI 0.19.1.
The CLI should have the ability to setup a virtual in-memory board, to ease development significantly.
Minor, but --ListFiles really should return the list of files sorted by name.
I think we're checking the OS version after flashing so it'll come back with whatever version we just flashed.
I suspect we can check the mono version instead.
And use the version in MeadowFileManager
app deploy appears to work even if OS files are missing, but it won't be able to deploy the BCLs so you'll get a missing DLL error
repro:
delete the local OS download and deploy an app to Meadow
Hey,
I had some trouble updating to B6.3, and wanted to let you know what I found.
I looked closely at the console output and saw that the issue was I had two active com ports.
The other is not a meadow, it's an unrelated intel thingo on my PC. (image attached)
Notice in the console output (again, image attached) that even when I specify the port to use (COM9), it only honours that for the first stage of OS Flash. Then it just reverts to the first COM port for the rest.
I worked around this issue by disabling the other COM port in device manager so that the F7 was the ONLY device available.
Thankfully this didn't seem to have any other effect on my PC :-)
Thanks!
Rob.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.