I have a panda and am using the cdc+debug interface and when the pc is rebooted the device always shows up as an “Unknown Device” in the usb controllers list in the device manager. Unplugging and plugging back in and the device shows up as it should. I’m using the routine below for firing up the cdc. Anyone ever seen this, know the cause, or can offer a solution?
_cdc = USBClientController.StandardDevices.StartCDC_WithDebugging();
while (USBClientController.GetState() != USBClientController.State.Running)
{
// Sleep for a while.
}
Tried on several different windows systems with same result. Haven’t tried CDC without debugging yet as I am waiting on usb to serial so I can set up for serial debugging.
Is there not anyone using the CDC+debugging interface on a device that is required to just be there on reboot without needing to unplug/plugin the device?
For testing the CDC without debugging I used the “Hello World” example code shown below. I also tried removing the write portion and just let it do nothing with the same results. The device was tested on laptop running Win7, old desktop running Windows XP, and a newish desktop running Win7 using a powered usb hub. The serial shield from GHI was used for the serial debugging interface.
using System;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.USBClient;
using GHIElectronics.NETMF.Hardware;
namespace USBClient_Example
{
public class Program
{
public static void Main()
{
USBC_CDC cdc = USBClientController.StandardDevices.StartCDC();
byte[] bytes = System.Text.Encoding.UTF8.GetBytes("Hello world!\r\n");
while (true)
{
if (USBClientController.GetState() != USBClientController.State.Running)
{
Debug.Print("Waiting to connect to PC...");
}
else
{
cdc.Write(bytes, 0, bytes.Length);
}
Thread.Sleep(1000);
}
}
}
}
Unlike the cdc+debugging when it works (doesn’t always) it comes up fine. The problem is though it doesn’t always startup the cdc interface. On all systems tested I did a test where I would just unplug/plug in the device and the cdc would come up most of the time, but not always and sometimes it would take several hot plugging before the virtual com port would come up. The powered usb hub seemed to be better behaved, but it still would not always work. These tests were run with just the panda board and nothing connected to it including the serial shield.
Here is the weird part. If the serial shield is connected (without anything connected to it) the cdc interface comes up every single time and on every single reboot. It always works. Based on my oberservations there seems to be something a miss with the cdc interface on the panda.
Is anyone using the cdc virtual com port interface on a panda board and getting reliable operation?
When you switch to Serial interface, the Serial RX, TX lines must not be left floating. If you connect pull-up on the RX, it should work.
Also, make sure the com port is closed before plugging the CDC device in Windows.
We will test Windows reboot while CDC is plugged in and see if we have the same behavior.
That would explain it. Works like a charm. Not being a hardware person it didn’t even cross my mind. That would be good info to put in the usb client section in the wiki [url]GHI Electronics – Where Hardware Meets Software
Revisiting this topic. Appeared was having issues still with the CDC driver, but it turns out the hardware the Panda was connected to keeps the usb ports powered on during a restart. This leaves the USB_CDC in a state where the system can’t initialize it after reboot so it comes up as an unknown usb device. For now I have solved the issue by periodically checking the USBClientController.State and recycling the USB_CDC object internally if it senses the state is no longer running. A StateChanged event would be useful so you could detect changes in the client controller state via an event instead of having to pull the information from the GetState() method.