Serial Comms dies in WinXP

Question

A bit of history: We have an application that was written many years ago (1998 is the first date in PVC, but the application is about 5 years older than this, since it was originally a DOS program). This application communicates with hardware through a serial port. When we got to Windows XP, we started getting reports that the application was dying after a short time. It seems that the serial number just “died” and the application remained stuck. The only way to recover from this situation is to restart the application.

The only information I can find on this problem was apparently due to the fact that the Windows Message system skipped this information, the buffer was full and the system was stuck. This piece of information has remained in the document of the old word, but there is no evidence to support this. It also mentions that this is common only at high bit rates (115200 +).

The solution was to provide customers with USB-> serial converters along with the equipment.

Today: We are working on a new version of equipment that will work both through the network and through serial ports. Therefore, to allow me to work with the network code, minus the actual equipment, we use the VSCOM NetCom113 device . It also sets up a virtual communication port for users (i.e.: mine).

Now I have the network code integrated with the application, it looks like the NetCom device is showing the same behavior as the physical symbol. This is undesirable since the application should run longer than 30 seconds.

Google returns the null problems we are experiencing.

It was interesting to me:

• Has anyone experienced this before? If so, what did you do to fix / fix the problem?
• Does anyone have any suggestions regarding the correctness of the original author of the document and what can I do to verify the theory?

Unfortunately, I can’t send the code because the serial code is closely connected with the rest of the system, although if you have questions about this, I can answer questions about this.

Update:

• The code is written using Win32 Comm routines, so I use CreateFile, ReadFile. There are also reasonable calls to GetOverlappedResult.
• It doesn't hang on its own, it's just that the comm stops. You can access the menu, click on the buttons, but nothing can interact with the connected equipment. Using realterm , you can see that no data is coming in or out.
• I think the link to the Windows message is that the problem is internal to windows. The data arrived, but the kernel lost it and thus did not inform the rest of the system about it.
• Flow control is not used.
• Writing a “simple” test is difficult because the code is tightly coupled and the underlying protocol is quite complex and will require a lot of work.

Answer 1

Are you using DOS-style serial code or the Win32 CreateFile approach?

If the former, be very suspicious: if at all possible, I will move on to the latter.

If the latter, do you know which system calls it a suspension? Do you block reading? or by an I / O call? or waiting at an event? (I'm not sure I have enough experience to help, but these are the questions that come to mind)

You can also check the size of the queue, which you can set using the SetupComm function.

I do not buy the material "Windows Messaging System" - it sounds suspicious; you can write a good Win32 serial I / O code that never uses windows messages.

edit: Are events with overlapping I / O used? I seem to be recalling something about auto-reset events that sometimes miss their trigger ... very carefully check your overlapping I / O calls to see if you are processing the possible results correctly. There may be a way to make your code more reliable by automatically canceling overlapping I / O and restarting another read. (I assume the problem is half reading, not half writing?)

edit 2:. Suggestion: if the win32 side missed a byte or packet, and your devices are stalled because they are both waiting for each other to answer something, can you configure serial input / output on the other side to send some type regularly counter ping packet? (and register ping packets on the PC side, so you can see that you missed one)

Answer 2

Are you sure you have configured flow control correctly? DTR, RTS, etc.

-Adam

Answer 3

I have applications using usb / bluetooth serial ports and never having problems. with bluetooth, I saw bit rates (stable) of 800,000 bps for long periods of time. most people mis implement port.

My serial port

Answer 4

Not sure if this is possible for you, but if you can rewrite the code using C # .NET, you will have access to the SerialPort class. This may solve your problem. I know a lot of legacy code based on the Win32 API for hardware I / O ports, which tend to fail in XP due to time (had little experience with MIDI).

Also, I don’t know if you can use the Win32 serial port access method in Vista so that you can disable future MS OSs from using your code.