Grief with a serial port

[ThermoSight]

Hi.
I am working with VS2010 C++, Windows 7 Pro, and a serial device.

The C++ app is unaffected by cycling power on the serial device. However, cycling power on the PC (Windows 7 Pro) causes the C++ app to fail (that is, when power is restored to the PC and Windows is rebooted, the app can no longer 'talk' to the device).

It is important to note that a C# tool can talk to the device regardless of power cycle of either the serial device or the PC. It just works!

Indeed, when the app fails, using the tool to 'talk' to the serial device restores the ability of the C++ app to talk to the device.

That suggests to me that the C# tool is doing something to the port (COM1).

I have determined by visual inspection that when it's failing, the DCB content is identical to that when it's working. I create a DCB, download the current DCB state via GetCommState, modify the DCB to fit my requirements (38.4, 8, n, 1), then SetCommState. I now also follow the SetCommState with another GetCommState to verify that the DCB is set as intended.

Also, I now, in my desperation, issue a call to ClearCommError immediately after the call to CreateFile, thinking that the port might be coming up in some error state after a power cycle. No help there.

After all of that, I issue a single character command to the device via the asynchronous WriteFile & GetLastError & WaitForSingleObject & GetOverlappedResult sequence. Of course, all indications are that all went well.

But the following ReadOverlapped fails unless the C# tool has been used to 'talk' to the device first.

So, bottom line,
a) I have observed the DCB with the debugger, and determined that it is good (or at least identical to the DCB content in effect when the app is working)

b) there are NO error indicators returned throughout the write and read process but the C++ app never sees any reply from the device (unless the C# tool has run at least once)

c) I have determined that when it IS running, the C++ app is indeed writing the correct command to the serial device and reading the device's reply correctly.

Any suggestions as to another item I might check ?

thanks

bill

[S_M_A]

Could it be that the serial device gets a stray character when the PC boots and that locks up the communication? Maybe the C# application knows how to resolve such a lockup?

When debugging serial communication issues sniffing the communication line is often very useful. Either use another computer (with 2 ports) or a special hardware like http://www.hardware-serial-monitor.c...ta-capture.htm (first I found. I bet there are cheaper stuff around)

[ThermoSight]

"Could it be that the serial device gets a stray character when the PC boots and that locks up the communication? Maybe the C# application knows how to resolve such a lockup?"

Hi S !

Indeed that seems quite possible. But I think it's not the C# application that knows how to resolve the issue, it's .NET's SerialPort class. I know because I wrote both the C# app and the Win32 C++ app.

What I must do is somehow determine what is wrong with the port (IF IT IS THE PORT!) and write the code to correct the condition explicitly ... I don't think Win32 has anything even remotely analogous to SerialPort. That is what I am attempting to determine with this plea for help. What are my alternatives, if any ? (Migrating to .NET is a non-starter, guys!)

re the hardware .... yeah I brought my laptop in this morning. It's old enuf that it has a serial port but the ol' frustration index began to climb when I found that I need a gender-bender (and probably a null-modem) to get the two PCs to talk to each other over the serial cable. I'll try it again t'morra if I can find the appropriate gender-bender, etc.

So, perhaps someone out there is very familiar with the serial port DCB and knows of something I missed or should try.

thanks all.

OldFool

[S_M_A]

Ok it sounds like it's more of a DCB issue even though you said that the DCB was the same for both situations. I live by the rule to assign every single field of the DCB just to be sure what I get. Mostly because I many years ago had an issue where the method GetCommState, a minimalistic change and then SetCommState failed when changing OS.

Maybe you forgot to disable the flow control?

What protocol does the device use? Is it possible to run it using a serial terminal software? If so I'd recommend PuTTY since it can be handy for other stuff as well.

Yes to listen on the communication you will need some hardware but such boxes are quite cheap and well spent money compared to do the soldering yourself. An example on (not so cheap) a hardare http://www.fte.com/products/serialanalyzers-RS232.aspx I've seen these for about the 10th of that price but failed to find it this time.