Skip to main content
update
Source Link

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!

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!

mentioned wrong terminal name
Source Link

If I use hyperterminalIONinja 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.

If I use hyperterminal 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.

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.

Source Link

RS232 Debugging: Vitrual PC USB Adapter vs True COM Port

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 hyperterminal 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