ComWrt function does not return. Application hangs.

[test_man]

I have this strange issue with ComWrt function. In my application I call ComWrt about 4 times a sec and it works ok for couple of hours then application hangs. When I debug my code I found out ComWrt function is highlighted and execution is waiting for it to return.

I use USB to serial convertor (FTDI chipset). Only way to recover from this "hang" is to disconnect USB cable.

This is not repeatable. Sometimes it works fine for days sometimes it breaks in 5-10 minutes.

When I open COM port I pass -1 as output queue size.

Any suggestion?

[jr_2005]

We had this symptom on a project a few years ago. Oddly enough, it only happened with a particular manufacturer's USB adaptor - when we changed brands the problem went away and the application was rock solid from then on. We put it down to poor device driver software from the original manufacturer.

JR

[menchar]

We use FTDI USB port as a virtual com port and use it with CVI.

We've had to take care to get the latest version of the FTDI virtual com port driver, it's fairly volatile and they update it frequently.

The virtual com port won't appear to the PC unless power is applied to the FTDI chip - so you have to take care that it gets started and stays up and running. 

I do still sometimes see weirdness on the virtual com port that I can't explain.  We cycle power on the HW and then it will work again.

USB to serial converters / dongles are notoriously unreliable - though NI's is reputed to work OK - you can still buy versions that just don't work well if you're not careful.  I don't know if NI's USB - serial dongle uses the FTDI chip however.

I've never liked USB - serial converters, even though it's serial to serial conversion.  I buy and use true serial com ports whenever I possibly can.

Menchar

[OVR_CZ]

hi,

    it is 4-5 years ago, but for similar reason,we move to CP2103 chips from www.silabs.com   

if you cannot move to this there are some hints(without point 4, i apply it for any serial communication)

1) do not use port functions in multiple threads. only in this where is opened. (also close it in the same thread)

    because not all drivers is fully threadsafe.(on one app, i have  unpredicable hangup after several weeks but sometims its hangup after several days)

2)if any of port communication functions return a error, do not call any other port function than close

   (for example,in case of unplug usb device, any next call can wait for 10..30 seconds before return to app)  

   (this is applied specialy with Ni serial library)

3)send whoole data telegram with one call of ComWrt non with serveral calls or ComWrtByte

   (some drivers has problem with sending 3*50byte but sending 1*1000byte is ok)

   (Ni library work good in any way, but with winapi you can see this manners very frequently.)

   (This also depends on settings,but however i have good results with application that fullfill this point)

   (also some drivers can add pause between data which is divided in multiple ComWrt calls)

   (this can be problem in communication with some microprocesors systems)

4) write you own kommunication library based on winapi (this point is lilte controversial)

   NI Serial library is very good and work with good drivers, but in case of bad drivers, somtimes hangup or break communication.

   i have good experience with winapi  communication(together with the previous point fullfiled)

   but with this solution,I lost too much comfort(in compare ti Ni Serial Library), and obviously it is point for new errors.

   so if previous point(1,2,3) do not help

   Instead of this point i recomend to switch to cp2103 or any other chip that works good to you.

[test_man]

I think I found the issue. It is very strange. 

In my application I have to change different parts for testing. And power supply used to power these parts and to power device attached to USB to serial port caused this issue. After changing power supply it worked fine.