We have been using your CP2102 USB to serial converter in our hardware for years. We have recently run into a problem running our hardware with windows 7. THe data being sent from the USB side to the serial side is corrupted when using a windows 7 machine with the SILabs windows 7 drivers. However that same hardware and cabling works fine when using an XP machine and the older drivers. Has anyone seen this problem before? We have a program that spits our a stream of data and waits for a response. When we run this program straight from a computer serial port, it works fine. When we run the program through the CP2102 using an XP machine it works fine. However when we run that program on a windows 7 machine the data is slightly corrupted.
Thanks for the advice on this.
Discussion Forums
Interface
Unanswered
What is the nature of the corruption (incorrect bytes, reordered bytes, missing bytes, etc.)? If it's just purely 'corrupted' where nothing make sense this could be a baud rate issue.
Preston, We have used the SILABS cp2102 in many of our instruments and they are installed around the world. So we need to get a handle on this problem. When using an XP machine (or an FTDI USB to Serial device) we see the following string: XHZE1PWGW TWdWWèWRWRHXZSXXXRYLWRH When using the CP2102 with a windows 7 machine we see: XHZE1PW TWdWWèWRWRHXZSXXXRYLWRH The commands PW and GW are followed by a two byte binary value, not shown. I tried to use PortMon but could not get it working. So this data is from realterm.
Thanks for your help, Matt
0
What are these binary values? And how do they map onto ascii control characters? Is software handshaking enabled by any chance?
0
I can see that there is 'missing' data here. The CP210x will not drop data unless some setting is wrong, or the device is used in a way that yields the behavior.
What are your issues getting Portmon working? If you can capture a log of a 'working' scenario and a 'non-working' scenario they can be compared. You can see things such as when a read times out, when a device closes (and maybe purges buffers), etc. This is the important information in solving the problem - I won't be able to determine anything from your ASCII output without more of the underlying information.
0
Here is the string that I expect to see coming out of the CP2102 into our instrument. this is the string we see when using the FTDI converter:
Here is what we see from the CP2102: X58 H48 Z5A E45 131 P50 W57 00 7F T54 W57 00 00 232 W57 W57 03 E8 W57 R52 W57 R52 H48 X58 Z5A S53 X58 X58 X58 R52 Y59 L4C W57 R52 H48
we are losing a bunch of characters after the W57 or after the W57 00.
Matt
0
Can you provide Portmon logs for both scenarios? To help you we need to have an idea of why the data is dropping. The CP210x driver will not simply drop data, so there is something else going on here.
One of the most common scenarios where data is dropped is if a device is closed before all data gets out of the device and the buffers are flushed. Is it possible you are writing a string of bytes and closing it before the buffer can empty?
0
I was able to monitor the serial port data using a tool called device monitoring studio. I monitored both the output serial port and connected to the output of the CP2102 and monitored the output of the CP2102. I pasted the results below.
Data sent to the CP2102: 000048: 14.01.2014 10:37:26.325 +0.0
58 X 002380: 14.01.2014 10:37:26.341 +0.0
48 H 002388: 14.01.2014 10:37:26.341 +0.0
5A Z 002396: 14.01.2014 10:37:26.827 +0.0
45 E 002399: 14.01.2014 10:37:26.827 +0.0
31 1 002408: 14.01.2014 10:37:26.832 +0.0
50 P 002411: 14.01.2014 10:37:26.832 +0.0
57 W 002414: 14.01.2014 10:37:26.832 +0.0
00 . 002417: 14.01.2014 10:37:26.832 +0.0
10 . 002425: 14.01.2014 10:37:26.832 +0.0
47 G 002428: 14.01.2014 10:37:26.832 +0.0
57 W 002432: 14.01.2014 10:37:26.832 +0.0
00 . 002435: 14.01.2014 10:37:26.832 +0.0
7F 002443: 14.01.2014 10:37:26.832 +0.0
54 T 002447: 14.01.2014 10:37:26.832 +0.0
57 W 002450: 14.01.2014 10:37:26.832 +0.0
00 . 002453: 14.01.2014 10:37:26.832 +0.0 --------------------------------------------------------------------------- Data output from CP2102: 004519: 14.01.2014 10:37:26.327 +0.0
58 X 004527: 14.01.2014 10:37:26.343 +0.0
48 H 004535: 14.01.2014 10:37:26.344 +0.0
5A Z 004579: 14.01.2014 10:37:26.829 +0.0
45 E 004587: 14.01.2014 10:37:26.830 +0.0
31 1 004595: 14.01.2014 10:37:26.834 +0.0
50 P 004603: 14.01.2014 10:37:26.835 +0.0
57 W 004613: 14.01.2014 10:37:26.836 +0.0
00 . 004621: 14.01.2014 10:37:26.837 +0.0
7F 004629: 14.01.2014 10:37:26.838 +0.0
54 T 004637: 14.01.2014 10:37:26.839 +0.0
57 W 004647: 14.01.2014 10:37:26.840 +0.0
00 .
0
This is only on Win7 ? ( XP and Win 8.x are ok ? )
If you connect this to a std terminal, and loop back the same data blocks, what do you see ? What Baud rate do you have ? How does it change, if you move that slightly ?
Your posted info suggests 4 bytes skipped, starting at byte #8, which are rather small numbers given the size of buffers in the device, and most SW.
0
It works with XP. We haven't tried win8. We used a std terminal and sent this string in at various speeds and at rates up to 115200. It worked fine. However when we use our INCC software this loss of data happens every time. Some times it skips after the first P and sometimes after the PW.
The data i posted was data looped back to a second serial monitor.
OUr INCC software runs at 9600 baud. We cannot alter the baud rate of INCC. It is very important that we get this working with the existing INCC due to the fact that this software exists all over the world. Making changes to INCC is not an option. INCC works with the FTDI converter as is. Are there tweaks that can be made to the CP210x driver? Thanks, Matt
0
There is a lot missing from your posted logs. I'd really like to see everything from the time your device is opened until it is closed (or the failure happens). I want to see what your settings are, order of events, etc. You should be able to attach two files, one for the 'working' case and one for the 'failing' case directly to a post. Unfortunately I have no way of detecting 'why' data is dropped by just seeing data only.
The fact that your loopback works fine means there is some corner case that is being hit in the production software. Seeing the actual log of what it is doing with the COM port will yield info on why the data is dropping.
Also, if this is affecting devices in the field I'd recommend contacting our customer support to get a more direct line of communication with our support team.
0
Okay. I have attached the transmit data (com6) and the data we see on the output of the CP2102 probing it with different com port, com3. Maximum attachements are 2. So I will add the com6 receive data on the next post.
0
Here is the com6 receive data.
0
The logs you are posting are exactly the same as you've posted in the forum - are you using the Portmon utility from the following link?
Trouble with CP2102 using WIN7
We have been using your CP2102 USB to serial converter in our hardware for years. We have recently run into a problem running our hardware with windows 7. THe data being sent from the USB side to the serial side is corrupted when using a windows 7 machine with the SILabs windows 7 drivers. However that same hardware and cabling works fine when using an XP machine and the older drivers. Has anyone seen this problem before? We have a program that spits our a stream of data and waits for a response. When we run this program straight from a computer serial port, it works fine. When we run the program through the CP2102 using an XP machine it works fine. However when we run that program on a windows 7 machine the data is slightly corrupted.
Thanks for the advice on this.
You can use PortMon on each system to see what the difference is in the communication and what settings are different between the two:
http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx
We have used the SILABS cp2102 in many of our instruments and they are installed around the world. So we need to get a handle on this problem. When using an XP machine (or an FTDI USB to Serial device) we see the following string:
XHZE1PWGW TWdWWèWRWRHXZSXXXRYLWRH
When using the CP2102 with a windows 7 machine we see:
XHZE1PW TWdWWèWRWRHXZSXXXRYLWRH
The commands PW and GW are followed by a two byte binary value, not shown.
I tried to use PortMon but could not get it working. So this data is from realterm.
Thanks for your help,
Matt
What are your issues getting Portmon working? If you can capture a log of a 'working' scenario and a 'non-working' scenario they can be compared. You can see things such as when a read times out, when a device closes (and maybe purges buffers), etc. This is the important information in solving the problem - I won't be able to determine anything from your ASCII output without more of the underlying information.
X58 H48 Z5A E45 131 P50 W57 00 10 G47 W57 00 7F T54 W57 00 00 232 W57 W57
03 E8 W57 R52 W57 R52 H48 X58 Z5A S53 X58 X58 X58 R52 Y59 L4C W57 R52 H48
Here is what we see from the CP2102:
X58 H48 Z5A E45 131 P50 W57 00 7F T54 W57 00 00 232 W57 W57 03 E8 W57 R52
W57 R52 H48 X58 Z5A S53 X58 X58 X58 R52 Y59 L4C W57 R52 H48
we are losing a bunch of characters after the W57 or after the W57 00.
Matt
One of the most common scenarios where data is dropped is if a device is closed before all data gets out of the device and the buffers are flushed. Is it possible you are writing a string of bytes and closing it before the buffer can empty?
Data sent to the CP2102:
000048: 14.01.2014 10:37:26.325 +0.0
58 X
002380: 14.01.2014 10:37:26.341 +0.0
48 H
002388: 14.01.2014 10:37:26.341 +0.0
5A Z
002396: 14.01.2014 10:37:26.827 +0.0
45 E
002399: 14.01.2014 10:37:26.827 +0.0
31 1
002408: 14.01.2014 10:37:26.832 +0.0
50 P
002411: 14.01.2014 10:37:26.832 +0.0
57 W
002414: 14.01.2014 10:37:26.832 +0.0
00 .
002417: 14.01.2014 10:37:26.832 +0.0
10 .
002425: 14.01.2014 10:37:26.832 +0.0
47 G
002428: 14.01.2014 10:37:26.832 +0.0
57 W
002432: 14.01.2014 10:37:26.832 +0.0
00 .
002435: 14.01.2014 10:37:26.832 +0.0
7F
002443: 14.01.2014 10:37:26.832 +0.0
54 T
002447: 14.01.2014 10:37:26.832 +0.0
57 W
002450: 14.01.2014 10:37:26.832 +0.0
00 .
002453: 14.01.2014 10:37:26.832 +0.0
---------------------------------------------------------------------------
Data output from CP2102:
004519: 14.01.2014 10:37:26.327 +0.0
58 X
004527: 14.01.2014 10:37:26.343 +0.0
48 H
004535: 14.01.2014 10:37:26.344 +0.0
5A Z
004579: 14.01.2014 10:37:26.829 +0.0
45 E
004587: 14.01.2014 10:37:26.830 +0.0
31 1
004595: 14.01.2014 10:37:26.834 +0.0
50 P
004603: 14.01.2014 10:37:26.835 +0.0
57 W
004613: 14.01.2014 10:37:26.836 +0.0
00 .
004621: 14.01.2014 10:37:26.837 +0.0
7F
004629: 14.01.2014 10:37:26.838 +0.0
54 T
004637: 14.01.2014 10:37:26.839 +0.0
57 W
004647: 14.01.2014 10:37:26.840 +0.0
00 .
( XP and Win 8.x are ok ? )
If you connect this to a std terminal, and loop back the same data blocks, what do you see ?
What Baud rate do you have ? How does it change, if you move that slightly ?
Your posted info suggests 4 bytes skipped, starting at byte #8, which are rather small numbers given the size of buffers in the device, and most SW.
The data i posted was data looped back to a second serial monitor.
OUr INCC software runs at 9600 baud. We cannot alter the baud rate of INCC. It is very important that we get this working with the existing INCC due to the fact that this software exists all over the world. Making changes to INCC is not an option. INCC works with the FTDI converter as is. Are there tweaks that can be made to the CP210x driver?
Thanks,
Matt
The fact that your loopback works fine means there is some corner case that is being hit in the production software. Seeing the actual log of what it is doing with the COM port will yield info on why the data is dropping.
Also, if this is affecting devices in the field I'd recommend contacting our customer support to get a more direct line of communication with our support team.
http://technet.microsoft.com/en-us/sysinternals/bb896644.aspx
I'd expect the log to look similar to this (note the IOCTLs and other details):
http://www.lucadentella.it/blog/wp-content/uploads/2011/10/portmon-t2.jpg