1
\$\begingroup\$

I want to compare RS232 traffic between two scenarios. Feel free to skip the background and jump right to the traffic logs. Can anyone explain to me why I may be seeing differences in these scenarios?

History
I have been trying to debug some RS232 communication issues between a very legacy hardware device and an application running on a Win98 PC. The comms between this PC and the device work perfectly, but I have not been able to get success with any other setups (virtualization, USB Com Port Adapter).

I'll cut out as much of the history as possible. I have an application running on a Win98SE Virtual PC (Microsoft) and on physical hardware running Win98SE.

On the Virtual PC side I am forwarding COM2 traffic to a physical COM port, which happens to be a USB COM Port Adapter.

After disabling FIFO buffers, the port appears to work without a hitch. I can transfer files between the real Win98SE PC and the Virtual Machine over the com port using HyperTerminal.

I did some PortMon analysis, and I found that the application repeatedly sends a particular set of bytes, sending this sequence of bytes to the hardware, I get varying amounts of data sent back to me.

However, when I run the application on the Virtual PC, I note that the application does not communicate with the hardware, it reports communication errors, data does not update, etc.

Traffic Logs
Running PortMon on the real PC, I get this sequence of typical communication (this works):

19  2:17:20 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 81 02 00 7E  
20  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
21  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
22  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
23  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : RXCHAR    
24  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS RECEIVE     
25  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
26  2:17:20 PM  COMAPP  VCOMM_ReadComm  COM2    SUCCESS Length: 1: 06   
27  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE    
28  2:17:20 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 80 02 00 7F  
29  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
30  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
31  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
32  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : RXCHAR    
33  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS RECEIVE     
34  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
35  2:17:20 PM  COMAPP  VCOMM_ReadComm  COM2    SUCCESS Length: 1: 06   
36  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE

Running PortMon on the Virtual PC, I get this sequence of communications (this doesn't work):

21  4:56:30 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 81 02 00 7E  
22  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
23  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
24  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
25  4:56:30 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
26  4:56:30 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
27  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
28  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
29  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
30  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
31  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
32  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
33  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
34  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
35  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
36  4:56:32 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE    
37  4:56:32 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 80 02 00 7F  
38  4:56:32 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
39  4:56:32 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
40  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
41  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
42  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
43  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
44  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
46  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
47  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
48  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
49  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
50  4:56:32 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE

There are some obvious differences: 1. The virtualized app excessively clears Comm Errors, when they don't appear to exist. 2. The virtualized app never receives RXCHAR, and thus never reads the 06.

I am very new to this kind of analysis, but what immediately comes to mind is that some of the signals (CTS, RTS, DSR, DTR, etc...) may not work with a USB COM Adapter, and perhaps the app requires these signals. Again, I'm no expert, maybe these signals are always required.

If I use IONinja to connect to the hardware, and send the same bytes I am capturing above, I do get the 06 response (among other responses), but the application does not recognize this.

I found this question, but it doesn't quite answer my question:
Disadvantages of USB to RS232 dongles

Update
At the suggestion/direction of @Chris Knudsen I've made a little hardware sniffer:
Hardware Sniffer

Turns out, Chris was correct. Portmon wasn't telling me about all the traffic.

Looking at the Rx communication, then the Tx communication, I can see that all the communication is in fact occurring as expected. However, timing may be compromised. It appears that in order to function as quickly as possible, it was coded to reject information delivered out of sync from the polling requests.

On closer inspection, I see that the software does work partially, with comm state toggling between "error" and "no error" and some data being partially visible.

In conclusion, the USB adapter is what is falling down here.
Consolation: I love my new hardware COM sniffer!

\$\endgroup\$
12
  • 1
    \$\begingroup\$ It would be informative to see the protocol of the "very legacy hardware device". This will tell us exactly what it expects from both software and hardware perspective of the serial port. Things like port configuration (speed, handshaking, etc), and the packet protocol (may bring to light some non-standard shenanigans that the old hardware expects). The only issues I've had with USB-to-Serial dongle include: windows: increased latency (which is sometimes configurable); Linux: driver incompatibility (a while ago). Consider Putty for a better diagnostic tool over Hyperterminal. \$\endgroup\$
    – Chris Knudsen
    Commented Jul 13, 2017 at 13:32
  • 2
    \$\begingroup\$ Also, to really see what's going back and forth, construct a hardware serial sniffer. Cut into the serial connection under test, tap into (but don't break) the wires for pins 2 and 3 and connect each to a terminal of a SPDT switch. Connect the common pole of the switch to Pin 2 (Receive) of a spare serial interface of your computer. Open another Com interface to this port, and watch the bytes go by. Change the switch position to monitor either Tx or Rx traffic. This type of debugging doesn't lie... I have a python script for monitoring, if you like. \$\endgroup\$
    – Chris Knudsen
    Commented Jul 13, 2017 at 13:39
  • \$\begingroup\$ Sorry, but this seems like an operating system / computer usage issue, not an electronic design issue. If one end of the conversation were your original hardware & software (or at least such that you had full source level access to modify and recompile) it might be on topic, but as is, this is really a serial drivers, virtualization, and PC usage question, to which the kind of techniques that would be used to debug a fitting design problem are largely inapplicable. \$\endgroup\$
    – Chris Stratton
    Commented Jul 13, 2017 at 13:49
  • 1
    \$\begingroup\$ @ChrisStratton I believe this has to do with the physical wiring of and function of an RS232 port through USB and natural COM adapters. There are similar questions on this topic in less detail that are not flagged off-topic. This question also has some background detail that may not be on-topic, but where else can I ask about RS232 signals and operation? \$\endgroup\$
    – Gorchestopher H
    Commented Jul 13, 2017 at 14:28
  • 2
    \$\begingroup\$ dropbox.com/sh/z7lsof53828zhth/AAAy8HvvTMsJARYQdQmJB5TTa?dl=0 link expires in a few days. Yes, Gnd too is good. \$\endgroup\$
    – Chris Knudsen
    Commented Jul 13, 2017 at 16:33

1 Answer 1

Reset to default
1
\$\begingroup\$

At the suggestion/direction of @Chris Knudsen I've made a little hardware sniffer: enter image description here

Turns out, Chris was correct. Portmon wasn't telling me about all the traffic.

Looking at the Rx communication, then the Tx communication, I can see that all the communication is in fact occurring as expected. However, timing may be compromised. It appears that in order to function as quickly as possible, it was coded to reject information delivered out of sync from the polling requests.

On closer inspection, I see that the software does work partially, with comm state toggling between "error" and "no error" and some data being partially visible.

In conclusion, the USB adapter is what is falling down here. Consolation: I love my new hardware COM sniffer!

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.