Hello,
in past we worked with FEZ Domino. Here we use the USB client for debugging an the connection to the PC. For this we had a virtual COM port.
Now we upgraded our system because of the Cerbuino to .NET MicroFramework 4.2 and the new GHI software.
When we connect a FEZ Panda II, the “GHI .NET MicroFramework Debugging Interface” will be installed but no COM-port. What we have to do to get the COM-port for communication?
This feature is no longer supported in 4.2.
o.k. but how does it work in 4.2?
What can we do? Do we need a machine with 4.2 for Cerbuino and an other with 4.1 for Panda?
You can use usb-serial module to get your data from the PC and only use USB for debugging. Would this be an option?
We removed all GHI + .NET MicroFramework and reinstalled .NET v4.1.
But when we connect Panda II we didn’t get the virtual COM port. If we connect FEZ Domino we have it!
Domino and Panda use the exact same chipset (USBizi) so I am not sure why you see anything different.
You need to put the Panda into CDC+Debug mode in code before the serial port will show up.
Yes, you are right!
When I run the command USBC_CDC cdc = USBClientController.StandardDevices.StartCDC_WithDebugging();
I get the COM port.
But now I have the problem that debugging dosn’t work after this command. The program runs, I can see it on the LED but no breakpoint works.
Do you see why GHI dropped this feature now? 
windows is not always happy.
Does it mean that if we use CDC, debugging does not work over the same USB cable?
You can use CDC but we no longer support StandardDevices.StartCDC_WithDebugging()
Hi Gus, is it still technically possible to maintain it or is it to focus your effort on something else? I mean, this functionnality is needed in our applications, this was a key factor when we have chosen to work with GHI products… May be this could be transfered in public domain and the community will maintain it. If no and that a feature of 4.2 is needed we will be in front of the wall…
We left it available in 4.2 but it is not supported.
Why do you need to ship product that has “debugging connector” anyways? Isn’t it better ot ship your product with clean CDC-only interface to your customer?
Ouch!!! You’re right, debugging is not needed on the customer side…
The fact is that when customers have problems, it is good to know that we can connect mfdeploy to see where the programs stops.
Yes, expose a header on your product where you can plug in your serial-usb cable and start debugging 
Your customer will be happier than seeing “debug interface” in device manager.
They do not take care about such thing and even if it was the case, we (I) don’t mind for now, since we (I) are still in dev stage, we (I) upgrade products every two weeks…
The debug interface is for me essential and as all com ports are already used… I have no other choice.
When our product will be reliable, Moving to standard CDC device will be possible.
Having some issues with CDC+debug (After a while, the EMX does not seem to send data on the port (debugger is still alive) while reception is still OK, I mean the EMX still receive data on the CDC but writing data on CDC does not seem to have any effect). I have seen on the forum that CDC + debug is not very reliable. Therefore I think it’s time to move to the traditionnal CDC driver and switch the debug interface to an other one.
The problem is that my application need all the com ports (one com port for the IMU, 2 com ports for NMEAs and one for the XBEE module). The idea is then to deploy with COM port but how to deploy a version of the program on a port that will be used for an other purpose.
Here’s the code I am using:
if(bp_pow.Read())
{
Debug.Print("Mode DEBUG demandé");
Configuration.DebugInterface.Set(Configuration.DebugInterface.Port.USB1,Configuration.DebugInterface.Port.USB1);
// Check debug interface
if(Configuration.DebugInterface.GetCurrent() != Configuration.DebugInterface.Port.USB1)
{ throw new InvalidOperationException("Interface must be USB."); }
cdc = USBClientController.StandardDevices.StartCDC_WithDebugging();
}
else
{
Debug.Print("Mode Client (cdc sans debug)");
Configuration.DebugInterface.Set(Configuration.DebugInterface.Port.Sockets1, Configuration.DebugInterface.Port.Sockets1);
cdc = USBClientController.StandardDevices.StartCDC();
}
I would have expected that on a fresh board when button bp_pow is pressed I can deploy the program and run the entire application using cdc + debug. This works well. The problem is that the board does not start on the second mode. Do i need to instantiate something for the socket?
Hum I have made an error, with the:
Configuration.DebugInterface.Set(Configuration.DebugInterface.Port.Sockets1, Configuration.DebugInterface.Port.Sockets1);
The tinybooter debug interface can not be a Socket… Could this be writing in red in the documentation? I’ve spent all this morning with this problem.
[edit] Now It seems that I’ve found a correct configuration for my needs.
The tinyclr debug interface has been set to socket1 and the tinybooter to usb1. Is this configuration seems correct?