Serial deploy to G80 with FEZ Config or MFDeploy

Are there any known issues with deploying an application to a G80 over a serial port using FEZ Config or MFDeploy? Or should it work?

Does anyone do this regularly with no problems?

I have only gotten it to work a couple of times out of probably hundreds of attempts by now. I’m not sure what the trick was. I tried power cycling the G80, closing and re-opening FEZ Config/MF Deploy, unplugging the cable and plugging it in again, different cables, rebooting the computer, switching computers, etc. and a couple of times it magically worked.

Are you able to see the G80 consistently when its plugged into the computer?

The COM port shows up, yes, but I can’t ping the G80 in FEZ Config or MF Deploy.

If I don’t pull the MODE pin low and connect a USB cable to the G80TH, yes I do always see the G80 in Device Manager. I can deploy and debug my application just fine over USB.

how are you connecting the Serial port to the PC? Do you have a reliable USB-serial port device? I rarely worry about Serial debug/deploy but have done it and have never had issues. I often use CP2102 cheap USB converters for that kind of task too.

Just thinking about this a touch more - to me this seems exactly like a situation that the device isn’t going in to serial debug mode; are you sure you’re re-powering it when MODE is low? Possible dodgy connection/solder joint?

Here is what I did and the results that I get:

(1) I have a G80TH with COM1 Tx/Rx pins connected to a GHI USB-Serial Gadgeteer module. That is connected to my computer’s USB port with a mini USB cable.

(2) This shows up as a COM port on my computer. :white_check_mark:

(3) I also have a micro USB cable connected to the USB client interface of the G80TH for deployment/debugging over USB. The G80 shows up in Device Manager. :white_check_mark:

(4) Using the USB interface, and can deploy and run my application just fine. :white_check_mark:

(5) I connected the MODE pin (PE15 on the G80TH) to ground, and reset the G80. Device Manager refreshes and the G80 is not longer shown as a USB device. :white_check_mark:

(6) I open FEZ Config or MF Deploy. In FEZ Config I select the COM port in the dropdown and hit Advanced > Connect (or F5). It says:

Connecting to COM5
Failure - Device is not connected or not responding. No response from device. :x:

If I use MFDeploy, I select the COM port and go to Target > Connect (or press F5). It says:

Connecting to COM5…Connected

But when I press Ping, I get:

Pinging… NoConnection :x:

(7) Resetting the G80 while supposedly connected via MFDeploy also does not show any of the output from the G80. :x:

(8) Deploying doesn’t work either. :x:

(9) If I close FEZ Config / MFDeploy and connect to the serial port at 115200 baud with Tera Term, I can reset the G80 and see:

ÿG80
Version: 4.3.8.1
Debug: COM1
LCD: 0x0
.NetMF v4.3.1.0
G80, Build Date:
Mar 28 2016 08:14:04
ARM Compiler version 410713

TinyCLR (Build 4.3.1.0)

Starting…
Created EE.
Started Hardware.
MSdbgV1R¨½ cWCreate TS.
Loading start at 80826d4, end 80a8660
Assembly: mscorlib (4.3.1.0) Assembly: Microsoft.SPOT.Native (4.3.1.0) Assembly: Microsoft.SPOT.Hardware (4.3.1.0) Assembly: Microsoft.SPOT.Graphics (4.3.1.0) Assembly: Microsoft.SPOT.TinyCore (4.3.1.0) Assembly: Microsoft.SPOT.IO (4.3.1.0) Assembly: System.IO (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.Usb (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.SerialPort (4.3.1.0) Assembly: Microsoft.SPOT.Hardware.PWM (4.3.1.0) Loading Deployment Assemblies.
Attaching deployed file.
.
.
. :white_check_mark:

So the G80 is working, pulling MODE low is working, the virtual COM port is working, the USB cable is working, the FTDI chip is working, etc. I think I’ve narrowed it down to FEZ Config / MFDeploy not working.

I would agree but why if you can deploy with USB do you need to deploy over serial?

I think you’ve omitted a very important (so we don’t get confused) step. Prior to, or as part of step 5, you must disconnect the debug/deploy USB connection - that connection can appear as a serial port (usually when you invoke USB Client capabilities) so to ensure that the COM port you’re connecting to is the USB-Serial device on COM1 you should remove it.

You said it works sometimes, right? Well it’s worked a non-zero amount, even if that’s a small percentage statistically. But my contention is that MFDeploy will NOT be flaky like this, it will either work or not if the conditions are the same (it’s basically unchanged since netmf 3.x, why would it behave unreliably) so I think there’s something else going on, and honestly phantom COM ports seem more sensible to me than MFDeploy not working.

Can I also check though, that you have tried this with a simple blinky app deployed (and deploying it again), and not just your own large codebase app? I wonder if what your app is doing is interfering with the debug engine that is used to communicate to the PC; do you have any serial port usage, or perhaps very tight looping?

The test above was done on my development computer. I am trying to deploy software to a device in my lab over serial where I don’t have the option.

Brett,

Thanks for the suggestions. I may not have put it in my description, but I have tried it with and without the other USB cable (for USB programming) connected. It doesn’t seem to make a difference. Also I’m sure that I have the right COM port number, and it works over Tera Term with the same COM port I selected in FEZ Config or MFDeploy.

I will check whether the deployed application makes a difference. My application does use another COM port. Not COM1, but the one that uses PD5 and PD6 (I forget the #).

1 Like

Do you have a 10k pull up on Com1 RX? the only reason I ask is because the pinout on the data sheet says its required.

It seems that when MFDeploy tries to use the serial port, it is being denied. No other running programs are using the serial port though, and I can close MFDeploy and open the port just fine in Tera Term. It seems that MFDeploy is blocking itself from using the port. Is this possible?

Here is a log from my Serial Port Monitor by Eltima Software when I hit Target > Connect (F5) in MFDeploy:

COM4
# Time Function Direction Status Data Data (chars) Data length Req. length Port
2654 15/01/2018 15:10:06 IRP_MJ_CREATE DOWN STATUS_SUCCESS C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2655 15/01/2018 15:10:06 IRP_MJ_CREATE UP STATUS_ACCESS_DENIED C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2656 15/01/2018 15:10:06 IRP_MJ_CREATE DOWN STATUS_SUCCESS C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2657 15/01/2018 15:10:06 IRP_MJ_CREATE UP STATUS_ACCESS_DENIED C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2658 15/01/2018 15:10:06 IRP_MJ_CREATE DOWN STATUS_SUCCESS C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2659 15/01/2018 15:10:06 IRP_MJ_CREATE UP STATUS_ACCESS_DENIED C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2660 15/01/2018 15:10:06 IRP_MJ_CREATE DOWN STATUS_SUCCESS C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2661 15/01/2018 15:10:06 IRP_MJ_CREATE UP STATUS_ACCESS_DENIED C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2662 15/01/2018 15:10:07 IRP_MJ_CREATE DOWN STATUS_SUCCESS C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2663 15/01/2018 15:10:07 IRP_MJ_CREATE UP STATUS_ACCESS_DENIED C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2664 15/01/2018 15:10:07 IRP_MJ_CREATE DOWN STATUS_SUCCESS C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4
2665 15/01/2018 15:10:07 IRP_MJ_CREATE UP STATUS_ACCESS_DENIED C:\Program Files (x86)\Microsoft .NET Micro Framework\v4.3\Tools\MFDeploy.exe COM4

No I don’t have a pullup on COM1 RX. I guess I missed the superscript 2 next to 69 in the pinout table. I will try this. I would love for the solution to be something so simple :grinning:

I can’t say definitively, but adding the 10 kOhm pullup resistor didn’t change anything the first few times I have tried it. I’m going to switch computers and try some more…

Have you tried using the new ‘TinyCLR Config’ ?
Ive often had trouble with FEZ Config on Windows 10, works fine, then for some reason chase tail for a bit before works again, often a reboot helps…

Did you try to show hidden COM devices in device manager when the G80 is not connected and deinstall the used COM devices?

@PTSS - I just installed TinyCLR Config and tried it. It does not suffer from the problem of being denied access to the serial port. I can select the COM port and hit the “Connect” button, and it opens the COM port successfully.

I can even then close TinyCLR Config, open MFDeploy and try to connect - which will fail with “STATUS_ACCESS_DENIED”, and then open TinyCLR Config again and it will open the serial port again.

However, it must not be getting the correct response from my G80 because it shows the status as “Connection failed.”

Upon further inspection, it is sending “GHIPKT1…” over the serial port instead of the “MSpktV1…” that MFDeploy sends. Does this tool only work with TinyCLR OS?

I think there is something wrong with how MFDeploy uses the serial port. Programs that work (e.g. Tera Term, TinyCLR Config) have a handle to the serial port named “\Device\VCP0”, while MFDeploy opens handles to all serial ports present on the machine and they are named “\Device\USBPDO-xx” where xx is some one or two digit number.

“\Device\VCP0” (working-style) is actually how the serial port is listed in HKLM\HARDWARE\DEVICEMAP\SERIALCOMM. VCP stands for Virtual COM Port.

I’m not sure what USBPDO is. “Physical Device Object”?

If you’re getting back GHIPKT1, that means TinyCLR is on the device. MFDeploy cannot be used with TinyCLR, only TinyCLR Config can. As you suspected, MSpktV1 is what you should see for NETMF.

1 Like

OK, that’s what I suspected. Do you at GHI know anything more about MFDeploy that might help me? Are there any known issues? Is it because I am using a virtual COM port? (It’s hard to find an actual serial port these days). Should MFDeploy work in Windows 10, 64 bit OSes, etc.?

Does FEZ Config use the MFDeploy API (the Microsoft.NetMicroFramework.Tools.MFDeployTool.Engine namespace)?

I have also tried to use the API to write my own program instead of using MFDeploy, but it shows the same behavior. My calls to the “MFDeploy.Connect” method always throw a “MFDeviceNoResponseException” exception, and monitoring the serial port shows a series of “IRP_MJ_CREATE UP” functions that have status “STATUS_ACCESS_DENIED”.