Serial port adapter occasionally does not flush buffered characters

USB Cables PL2303-DB9
1

I’m using the PL2303 USB serial converter to communicate with ASCII characters between a Windows 7 PC and a remote UART at 38400 baud. The terminal software on the PC is teraterm.

Two way communication between the PC and the UART is generally stable until a large (but variable) number of characters is sent from the UART to the PC. When this happens, the PLC2303 appears to buffer the latest one or two characters coming from the UART and refuses to flush them to the PC until new characters are received. As characters are received at this point, the newly received characters are buffered, and the old buffered characters are pushed to the PC.

Using teraterm to reset the serial port will correct the behavior at the expense of dropping the one or two buffered characters.

2

Hi Jim,

Thanks for your patience and for the great description of what you’re seeing. Just to set expectations, because we haven’t seen this before, I’m not sure if we’ll be able to solve this, but there is some hope in the serial port settings …

Serial has a number of optional and legacy flow control mechanisms (RTS/CTS hardware lines; XON/OFF characters; etc)

The two sides must be configured to use the same flow control mechanism (there’s no automatic negotiation – it’s not plug and play)

Have you already played with flow control? What method are both sides configured for?

The best hope I think is that an alternative flow control setting may trigger the host driver to flush all characters more aggressively.

Thanks for trying some alternatives and letting us know if we can help!
Bernie

3

Hi Bernie,

Thanks for the response.

I already tinkered with flow control. Hardware flow causes all communication to stop. XON/XOFF appears to have no effect. The adapter does not appear to drop or to have trouble receiving characters. It just appears to stop flushing the final one or two characters after a long stream of communication. I also tried varying and disabling the FIFO settings in Window 7’s driver control panel without success.

Is there something else that I can try? This is a very vanilla serial port application that we have had working for several years with standard PC COM ports.

Jim

4

Hi Jim,

Thanks for letting us know.

The Windows serial APIs are designed to handle this kind of case with a flush of remaining data after a timeout period (http://msdn.microsoft.com/en-us/libra…)

So I believe it’s possible for a terminal application to handle this. Is your application tied to Terra Term, or do you have the option of using another terminal app like hyperterm, putty, etc?

We’ve also put the question in to Prolific (although that’ll probably be hit and miss on an answer).

Thanks for letting us know if other terminal apps are an option. Thanks!
Bernie

5

Hi Bernie,

I have putty 0.61 on my machine. When I tried it with the USB adapter, I experienced two blue screen crashes on Windows 7 when working with the same output as teraterm. I wonder why putty gets crashes and teraterm only gets buffered characters. Could this be a driver issue? I am will to try other (free) terminal apps if you have any suggestions.

Jim

6

Is there an update on this? My boss is getting similar blue screens with putty and the same model of adapters.

7

Hi Jim,

Thanks for pinging us for an update! We don’t have any additional info from Prolific, but one interesting aspect of the problem is we’ve not been able to recreate the blue screen between Win7 systems here – I believe it’s happening, but perhaps particular versions of driver & software are required to hit the problem.

Could you let us know what version of the Prolific drivers you’re currently running? You can get them from device manager by right clicking on the adapter

!](https://s3.amazonaws.com/satisfaction-production/s3_images/600766/win7-pl2303-db9-device-manager_inline.PNG)](https://s3.amazonaws.com/satisfaction-production/s3_images/600766/win7-pl2303-db9-device-manager.PNG)

And look at the “Driver” tab

!](https://s3.amazonaws.com/satisfaction-production/s3_images/600768/win7-pl2303-db9-device-manager-driver_inline.PNG)](https://s3.amazonaws.com/satisfaction-production/s3_images/600768/win7-pl2303-db9-device-manager-driver.PNG)

Thanks for letting us know! We would like to figure out the combination that can recreate the problem.

Another interesting datapoint would be the result with Hyperterminal Private Edition. This is the commercial terminal app that used to be included in Windows. A 30 day trial version is here: http://www.hilgraeve.com/hyperterminal/

It may not be a good long-term solution, but it could be a good datapoint.

Thanks for your patience while we try to figure out the best alternative here,
Bernie

8

I am using the latest driver from the website - version 3.3.17.203. My boss is using the version from the CD, so it is probably somewhat earlier. When I get a chance, I will try hyperterminal.

9

Thanks, Jim. I’m eager to get this solved, so we’re working it from several angles.

It’ll be great to know if Hyperterminal is a good workaround.

Thank you!
Bernie

10

FYI, I am came here to report this exact same problem with TeraTerm v4.71 running on Windows7 using driver v3.3.17.203. However, PuTTY v0.61 works fine for me and does not exhibit the buffer issue. Thanks.

11

Hi Bernie,

Hyperterm gives me the same results as putty. They appear to work well for a little while followed by a blue screen crash.

Where do we go from here?

Jim

12

Hi Jim,

Thanks for checking up on this. We’re still seeking a solution with Prolific.

Based on what we know so far, this does appear to be a driver problem that will require an updated driver package from Prolific.

For background, this is the low-level error/problem (copied out of !analyze -v of the dump)

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.

From the stack, it looks like the problem is both the Windows Driver Foundation core components (wdf01000.sys from Microsoft) and the Prolific ser2pl64.sys driver are completing the same IRP, which then triggers this crash.

It’s looks like a race condition that happens intermittently on some machines.

Unfortunately, driver updates can take weeks or months typically. If you’re able to hang with us to work through this, thank you. If not, we totally understand and would be happy to give you a full refund. Just let us know at support@plugable.com if you want to go that route.

There’s still a chance that an existing driver update in the pipeline has already resolved this issue, but there’s been no sign of that yet – so I don’t want to set expectations too high.

Again, my apologies. Just let us know what you’d like. And we’ll keep updating here.

Thank you!
Bernie

13

Do the problem fixed? I have the same problem

14

Hi hcccc.chung,

Thanks for your post. We’ve been working with Prolific on this issue and there is a newer driver available here:

http://www.prolific.com.tw/support/fi…

Let us know if you have improvement with this driver package. We’re still testing and so far have had good results.

I hope this helps,
Jerome.

15

Hi All,

There’s an updated driver available for Windows that should solve the Blue Screen problems and seems to address the buffered character flush problems as well. It’s still brand new but our testing has been very promising.

Here’s the link,
http://plugable.com/drivers/prolific/

Please do post back with you experiences.

Thanks,
Jerome.

16

Link takes you to page that says the driver is version 1.5.2, but the download is for 1.4.17.

What’s going on?

Scott

17

Hi Scott,

Sorry for the mix up, here’s the link again.

http://plugable.com/drivers/prolific/

Thanks,
Jerome.

Plugable Technologies

18

New driver seems to fix the character drop problem that I was experiencing. Thanks.

19

Hi Jim - Thanks great news! Thanks for your patience while we worked with Prolific to get an updated driver for this issue!

20

Hi,

I also facing such problem, even after upgrade the driver to the mentioned version (3.4.36.247).
Is there any temporary solution while waiting for the driver update to fix this?