Serial port hang/freeze

Question

On rare occasions my application freezes.  What I believe is happening is that the VISA Read or VISA Write vi never returns.  (The program is an executable, so I can’t go to the diagram to be sure.  I just released a new version that will help me isolate it further, but it takes time to propagate new software to users.)  I do have the timeout set to 500ms, and I know this works because it timeouts when I have no hardware attached.
When the freeze happens, I have to go to the Task Manager to kill my application; however, it never actually quits.  It goes away on the Applications tab, but won’t leave the Processes tab.  Selecting End Process on the Processes tab won't make it go away either.  I can get it to go away, however, by unplugging the USB cable.  I then plug the cable back in, relaunch my application, and all is OK.  (A restart works, too.)  I am using the FTDI 2232 USB to dual serial port chip (set up for RS485) in my system.
My first question is whether anyone has seen this before or has a suggestion to get this work.
My second question is how do I figure out what is actually hanging?  My LabVIEW 8.5.1 executable calls a VISA 4.41 driver.  The VISA driver calls a Windows COM port driver.  The Windows COM port driver calls the FTDI driver (Version 2.4.6).  The FTDI driver calls the USB driver.  We are running Windows XP with all updates installed.
I have about 50 of these systems running continuously.  I see about one freeze like this once every few days on a random system.  I am not able to reproduce it on demand.  Any debug solution will have to be deployable to all 50 systems; otherwise, it is possible that I won't see the bug for weeks, if ever.
Thanks in advance for the help.
Matt K.

Answer 1

Just dug out the email from FTDI support....
Blue 
Hello,
If it is an application problem then what could happen is you ask to read 10
bytes but only receive 5. The application would appear to hang waiting for
the remaining 5 bytes unless you have set timeouts to allow the read to
abort.
The fact you need to unplug and re-insert suggests the driver needs to
reload.
This could in theory be a result of a surprise disconnect.
What this means is the device handle is open and the device disappears from
the PC (like unplugging - but could be an EMC/noise event).
When the device re-appears to the PC the handle and the hardware no longer
match as the stack is not maintained during a disconnect.
This would result in you not talking to the actual device but some "rogue"
device handle which could theoretically hang the application.
Some ideas for debug:
1.
Verify the driver version installed is 2.04.06
http://www.ftdichip.com/Drivers/CDM/CDM%202.04.06%20WHQL%20Certified.zip
2.
Ensure you have set read and write timeouts in your application
3.
Use WM_DeviceChange to determine if you are disconnecting.
http://msdn.microsoft.com/en-us/library/aa363480.aspx
4.
Try increasing the resetpiperetrycount to make the device more immune to
noise events.
http://www.ftdichip.com/Documents/AppNotes/AN_AdvancedDriverOptions_(FT_0000
73).pdf