Situation: Using a Project Lab v3
Dev machine is Windows 11
Have only been able to deploy one simple app to it.
If I try again I get to:
Connecting to Meadow on com9
And it goes nowhere from there!
I have redone setup DFU, I etc. DFU check as below concurs with Scotts:
I did an OS reinstall and it it also hangs at the first connecting to com9
DFU check concurred with Scotts
Found DFU: [0483:df11] ver=2200, devnum=23, cfg=1, intf=0, path="1-1.1.3", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="20603861554B"
Found DFU: [0483:df11] ver=2200, devnum=23, cfg=1, intf=0, path="1-1.1.3", alt=2, name="@OTP Memory /0x1FF0F000/01*001Ke,01*032 e", serial="20603861554B"
Found DFU: [0483:df11] ver=2200, devnum=23, cfg=1, intf=0, path="1-1.1.3", alt=1, name="@Option Bytes /0x1FFF0000/01*032 e", serial="20603861554B"
Found DFU: [0483:df11] ver=2200, devnum=23, cfg=1, intf=0, path="1-1.1.3", alt=0, name="@Internal Flash /0x08000000/04*032Kg,01*128Kg,07*256Kg", serial="20603861554B"
OS Reinstall got to:
Erase done. [=========================] 100% 2097152 bytes
Download done. [=========================] 100% 2097152 bytes
File downloaded successfully
Transitioning to dfuMANIFEST state
Warning: Invalid DFU suffix signature
Connecting to Meadow on com9
Then hangs
When I pull th eplug here after waiting several minutes I get:
ERROR
Meadow.CLI.Core.Exceptions.DeviceNotFoundException: Could not find a connected Meadow with the serial number 20603861554B
The earlier install that worked at that point continued thus:
Erase done. [=========================] 100% 2097152 bytes
Download done. [=========================] 100% 2097152 bytes
File downloaded successfully
Transitioning to dfuMANIFEST state
Warning: Invalid DFU suffix signature
Connecting to Meadow on COM9
Meadow StdInfo: Mono will not start - version mismatch: Meadow.OS version 1.3.0.0, Mono version 1.2.0.1, Mono disabled
Meadow StdInfo: Mono is disabled
Writing C:\Users\david\AppData\Local\WildernessLabs\Firmware\1.3.0.0\Meadow.OS.Runtime.bin runtime
Starting File Transfer...
It seems that if I try try to enter any board focused meadow commands it hangs as above.
A. It’s defintely some sort of downlaod issue. In VS I get the following:
1>------ Deploy started: Project: MeadowApplication23, Configuration: Debug Any CPU ------
1>
1>Connecting to Meadow on COM9
After several minutes I give up an unplug the lead. In a short while the mesage:
1>[16/09/2023 2:33:04 PM] Deploy failed: A device has not been selected. Please attach a device, then select it from the Device list.
1>StackTrace:
This reproduceable. Same outcome if I wait longer times.
So it most know about COM9, in particular its in the dropdown list and knows its been unplugged (ithink)!
B. Similar outcome with this:
PS C:\Users\david\Documents\meadow> meadow use port com9
Setting port to com9
Done!
PS C:\Users\david\Documents\meadow> meadow mono disable
Connecting to Meadow on com9
Give up and unplug:
Unable to find Meadow.
PS C:\Users\david\Documents\meadow>
C. But if I do same but start with it unplugged:
PS C:\Users\david\Documents\meadow> meadow mono disable
Connecting to Meadow on com9
Unable to find Meadow.
PS C:\Users\david\Documents\meadow
So my conclusion is that it does know about the device on COM9 with the device connected (and knows there is no device when not connected) but fails to interact with it!
One more attempt on this:
djaus@raspberrypi:/media/djaus/C020-1602/meadow $ dotnet meadow.dll flash os
Flashing OS with /home/djaus/.local/share/WildernessLabs/Firmware/1.3.0.0/Meadow.OS.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08000000, size = 2097152
Download done. [=========================] 100% 2097152 bytes
File downloaded successfully
Transitioning to dfuMANIFEST state
[null]
Connecting to Meadow on /dev/ttyACM0
And again it just hangs!
My conclusion is the same as previous: The problem IS at the device end.
Is it possible to do some sort of FACTORY RESET of the device?
Back on my PC. Running the meadow app from Visdual Studio in debug mode:
meadow download OS runs OK 
meadow flash OS hangs again ;(In the code when it runs it gets to the Connecting to Meadow on line of code as below:
logger.LogInformation($"{Environment.NewLine}Connecting to Meadow on {serialPort}{Environment.NewLine}");
var createTask = Task.Run(() => meadow = new MeadowSerialDevice(serialPort, logger));
var completedTask = await Task.WhenAny(createTask, Task.Delay(1000));
if (completedTask != createTask || meadow == null)
{
logger.LogTrace("Timeout while creating Meadow");
try
{
await createTask;
… but the completedTask returns as runToCompletion when it should be CreateTask which means it is running. And meadow is null.
It then procedes to the await createTask line of code and does not return.
Drilled in further. This LOC fails to open the serial port which now has switched from DFU mode to COM9
var port = new SerialPort
{
}
....
port.Open();
Nb: COM9 is nlisted at this stage in some code that gets a list of COM ports.
The problem is that port.Open(); never returns.
Just noticed in the Port class instantian // This value is ignored when using ACM
Does this mean that at this stage the port should still be DFU/ACM mode and that is what shuld be being openned?
Trapping the port.Open() (in a loop) in try - catch ex.Message:
Exception thrown: 'System.IO.IOException' in System.IO.Ports.dll
The semaphore timeout period has expired.
Timeout takes 4000 seconds, the read timeout.
In next loop get:
System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'
Footnote: If, in the catch code just above, the port is disposed of and reinstatiated, it doesn’t have the access violation, Just in a neverending loop!
Hint: Found can skip reflashing the DFU with -d additional command line prarameter
meadow flash os -d
But need to boot in COM mode
My intepretation of that code is incorrent. the completedTask is the CreateTask so all is OK.
The problem is that that task returns with meadow null hence that reason is the reason it goes into that following loop. CreateTask in teh loop does not return. So it is the call …
meadow = new MeadowSerialDevice(serialPort, logger));
… that is supposed instantiate the MeadowSerialDevice which fails.
This worked:
Try:
> meadow download os -v 1.3.1.3
> meadow flash os -v 1.3.1.3
Flashing 1.3.1.3 (and 1.3.4.0) does not solve my problem. Still hanging in “Connecting to Meadow on COM…”. The Meadow.CLI Version is 1.3.4.
