Living without MFDeploy

[WilliamAtSamraksh]

I understand there's a move afoot to drop internal support for MFDeploy. Here's what I see as the practical impact.

• On the .NOW it is often the case that I can't get deploy to work from Visual Studio. (Oddly, it consistently deploys onto a WLN.) In that case I use MFDeploy to reboot into TinyBooter, erase the deployment, reboot into TinyCLR and then deploy from VS. It's a chore but not too difficult and I can do it all in a single GUI. A JTAG script to do the erase could be used but now I'm having to drop back to the command line, locate the script, make sure the .NOW is connected to the JTAG and run the script. This also presupposes that I'm configured correctly for my particular JTAG.
• In MFDeploy, when a mote is connected to TinyCLR, there's an option to erase the program storage section without affecting anything else. This is very convenient. The alternative is to do the JTAG script thing again, but with a different script.
• In MFDeploy, updating the TinyCLR (aka eMote runtime) can be done conveniently in MFDeploy. With JTAG there's another script with the added complexity of specifying the location of the correct .axf file.
• Our customer user doc (for app notes for instance) will have to be re-written to teach them how to use JTAG for the MFDeploy tasks.

If we really do make the switch to MFDeploy then at the very least we need to provide a GUI that will let the user configure a JTAG and easily execute the necessary JTAG scripts with feedback as to success/failure. That is, we should at least duplicate the core functionality of MFDeploy.

[Nathan-Stohs]

There is no desire to drop support for MFDeploy. Rather, we speculate that MFDeploy is being abandoned by Microsoft which may force our hand. This given how much pain there is associated with getting MFDeploy to work on the WLN. All appearances are that this is a software problem and seems to be simple neglect, at least of the serial port management path. There are threads running to get more information on all of these points.

For instance it was reported (in the call) that MFDeploy does not work for people but app deployment from VS works fine. The most likely narrative then is that the MFDeploy serial stack hasn't kept pace with Windows 10 and latest .NET. I personally have never had trouble on my Windows 7 machine (I'm also frugal on updates/installs). Please do add any data points you have on this.

At this point I believe we are still looking for answers. I don't think JTAG is being pushed as the user alternative.

[ChrisAtSamraksh]

If there is a particular program on the .NOW that is giving you trouble when deploying from VS let me know. I suspect it could be a program with the radio turned on, which then receives a packet and interrupts during a deployment thus causing timing issues. If that is the case, I can include the radios as drivers that need to be shutdown before we deploy.

I plan on testing MFDeploy with the version I compile myself using VS and thus gaining visibility into why we can't even ping the WLN. I will probably get to that Monday.

[KennethAtSamraksh]

There is actually some desire to abandon support for MFDeploy. As a marketing position it’s a little out of touch.

This is not, yet, overwhelmingly compelling. But it was never ideal and the direction is decidedly trending towards being less of a fit in the future.

If it’s really true that no-one else has made it work on Windows 10 then our hand is forced and we must do it now. I don’t think this is true. I think we have Windows 10 problems that others have worked out. Don’t blame our bugs on Microsoft.

On the other hand I seen no big reason to fight this, unless the fix is somewhat easy. Let’s move on and not worry too much about it.

Kenneth W. Parker, Ph.D.

From: Nathan Stohs [mailto:notifications@github.com] Sent: Friday, September 23, 2016 12:34 PM To: Samraksh/MF MF@noreply.github.com Subject: Re: [Samraksh/MF] Living without MFDeploy (#455)

There is no desire to drop support for MFDeploy. Rather, we speculate that MFDeploy is being abandoned by Microsoft which may force our hand. This given how much pain there is associated with getting MFDeploy to work on the WLN. All appearances are that this is a software problem and seems to be simple neglect, at least of the serial port management path. There are threads running to get more information on all of these points.

For instance it was reported (in the call) that MFDeploy does not work for people but app deployment from VS works fine. The most likely narrative then is that the MFDeploy serial stack hasn't kept pace with Windows 10 and latest .NET. I personally have never had trouble on my Windows 7 machine (I'm also frugal on updates/installs). Please do add any data points you have on this.

At this point I believe we are still looking for answers. I don't think JTAG is being pushed as the user alternative.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Samraksh/MF/issues/455#issuecomment-249240189, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA-4xLJRw0mP8PO8cxRRHkHnM-BmsLeEks5qs_9hgaJpZM4KFIzm.

[WilliamAtSamraksh]

@ChrisAtSamraksh: It's possible that the radio on is a common factor; I hadn't kept track. In any case, there's no reason to have the radio enabled while VS is deploying a program, so turning it off doesn't seem to have a downside.

[ChrisAtSamraksh]

I actually have zero problems using VS to deploy a program even when running OMAC. I have not failed to deploy in a long time.

Is there a program that is having issues with deploying?

[ChrisAtSamraksh]

I worked a couple hours on getting MFDeploy to work on Windows 10 with the WLN.

It is a strange problem. I compiled MFDeploy on my own and I have no problem opening a COM port to a .NOW. MFDeploy is unable to open the COM port to a WLN. It fails right there. This is confirmed by a serial port sniffer. MFDeploy just can not open the WLN COM port.

The stranger thing is that if I just write a trivial SerialPort C# app I can open the WLN COM port with it and send/receive data, but that is using the SerialPort class. The line that MFDeploy fails on is: SafeFileHandle handle = Native.CreateFile(file, Native.GENERIC_READ | Native.GENERIC_WRITE, share, Native.NULL, System.IO.FileMode.Open, Native.FILE_FLAG_OVERLAPPED, Native.NULL); "file" here is the COM port.

The parameters are all correct (i.e. they are basically the same as when it opens correctly with a .NOW) but it will fail to get a valid handle. Looking at the Device manager I can't see any difference between a COM port of a WLN and a .NOW.

[Nathan-Stohs]

Is it still the case that the proximate error returned is insufficient permission to open the port?

How does the SerialPort class ultimately create the handler? My initial reaction is that the above method is perhaps not a robust way to do it and its possible we could replace. (EDIT: to be clear, that's just a guess)

Alternatively I'd assign a decent probability to a more or less random bug somewhere on the PC end. It's hard to get an immediate permission error out of hardware. And of course, I haven't been able to replicate on my Win7 PC.

Very hard to explain why the WLN and .NOW are different. WLN uses a CP2104 chip and .NOW uses a CP2105. Very similar. Older .NOWs in fact did use the CP2104 and I've asked Chris to look at an older .NOW where we used the CP2104 and see what happens.

[ChrisAtSamraksh]

I got it working. MFDeploy enumerates a USB which seems to lock the CP2104 chip up. If I comment out the USB enumeration then MFDeploy has no problem opening the COM port on the WLN. I will email out the MFDeploy without the USB enumeration.