CCS Usb device driver reliability

[russk2txb]

I have got my test project for the PIC 18F14K50 done and works well, but I have a lot of connection issues. I am using the CCS USB to UART, SERIAL DEMO driver (cdc_NTXPVista.inf), with Windows XP Pro. When this driver is first installed it works well. I can connect using the COM Port (Like COM10) or the USBSER001 id. However whenever I disconnect the USB cable and reattach it, something goes wrong.

Usually the PC Program (HyperTerminal or my own program) will fail to connect, giving error 2 (no device). Originally I found that if I switch the usb connector to my second usb jack on the PC then a new COM port would be assigned and will work. But after that, nothing by a reboot would get it working again. That means that uninstalling the driver and reinstalling it does not help. Device manager continues to show that the old assigned COM port is the correct one (but will not work). A reboot clears both ports and allows a new one to be assigned.

I have tried all manner of methods to try to avoid the reboot, including removing all instances of the USB device in the registry, but the PC continues to remember and try to use the old port.

Then I wrote code to enumerate all USBSER devices and display them for selection in my PC program. That revealed that a new USBSER # and a new COM port were being assinged after a disconnect and reconnect. Yet Device manager (and the program USBDView) continue to show the old device and port number only (as does Hyperterminal). Usually this new USBSER device number will connect, and sometimes it will work properly, but often it only works for a short time and then hangs the USB connection.

As you can probably tell by now, I am a newcomer to USB programming, yet I am wondering about the reliability of the CSC supplied device driver. Does anyone have any suggestions or advice?

Somewhere I thought I read that the CCS drivers are not intended for production use, but I cannot find this now. How would one go about obtaining a driver that is production quality?

Thanks, Russ

[asmboy]

research the FTDI FT232R

i've used this part in many projects and even had to document it, and its Win driver's , EXCELLENT fault tolerance for life science critical applications.

the integrated USB features of the pic family, IMHO, are of such code bulk and complexity compared to VCOM ports implemented via this sort of hardware, - that i simply won't consider the Microchip integral USB functions for any purpose.

i am still keeping a useless ( to me) inventory of many different USB enabled PIC devices that i simply will never use, or consider designing into a new project.

i would love to hear however, of an application where the integral USB functions are needed and can outperform the max baud rates that the FT family Vcom chips provides.

[Ttelmah]

The standard PIC drivers can be made to work OK though.
Key question is how the slave device detects that the connection has dropped?.
You really need two 'layers' to this:
1) Hardware detection of the connection - use the connection sense. It helps a _lot_.
2) Use the DTE/DCD settings to detect in the PC code that the device is present (and disconnect when it isn't), and also in the slave to detect that the master has disconnected.
So your main code 'loop', needs something like:

[FvM]

I don't want to argue against FTDI chips in general, they serve their purpose and I've used them in a number of designs. But you get pretty powerful PIC processors for the price of a FT232, or you can reduce overall costs and part count respectively. If you want to implement other device classes than basic serial port, there's no competition anyway.