none
SerialPort.ReadByte() from USB "virtual port" RRS feed

  • Question

  • Using win8, x64. .NET 4.5 and "ST-Lab USB Serial Cable" with Prolific driver ser2pl64.sys version 3.4.48.272.

    I open a port and just go directly into a read loop with port.ReadByte().
    If the buffer is empty when ReadByte() is called, it generates an IOException (The I/O operation has been aborted because of either a thread exit or an application request.).

    If I run the exact same code using a real physical comm port (driver is serial.sys), it just waits nice and quiet waiting for a byte (as expected).

    There is no port.Close() being run, there is no GC taking down the port etc.
    I have included resetting dcb AbortOnError just prior to opening the port.

    Any clue why this happens ?
    B.t.w. it seems to not happen if I register for the DataReceived event instead, but I prefer a simple readloop with blocking ReadByte() calls in own thread.

    Wednesday, June 12, 2013 9:37 PM

Answers

  • Tried again after several updates, now the driver (ser2pl64.sys) version = 3.4.62.293.
    Problem disappeared :)
    (And I still believe I was not alone having this problem)

    Only tested on Windows 8.1, will test on Windows 7 soon...

    • Marked as answer by EuroEager Tuesday, November 5, 2013 2:51 PM
    Tuesday, November 5, 2013 1:55 PM

All replies

  • YOu may be having problems with the RTS/CTS control lines.  Try truing of hardware and software controls before opening the port. I suspect the port is being closed because of these settings.  If not disconect, I/O device on the connector and see if you have the same problem.  the cable to the device may be wired wrong.  We had USB to RS-232 device at work and it turned out one of the 9 pin connectos or the device was connected to 5V inside the PC.  The cable we were using add the 5V wired to the I/O device which had the same pin connected to ground.  We simply opened the wire to the 5V pin.

    jdweng

    Thursday, June 13, 2013 12:59 AM
  • Thanks for your effort, however port.Handshake = Handshake.None;
    Please note my info regarding DataReceived event, why should this work if port gets closed ?
    Device (RS232 device to be connected to ST-Lab) connected or disconnected, no change.
    5V to PC, perhaps, will try to check later on today.
    I didn't medntion earlier, but all is ok if using HyperTerminal instead of my .Net program, why this if port gets closed ?
    Thursday, June 13, 2013 6:08 AM
  • What baud rate are you using?  Is it the same with HypeerTerminal as your application?  Check the date of the hyperterminal exe file.  I curious if it is a 32 bit or 64 bit application and the date will let me know which one it is.  Check to make sure no ASYN event handlers have been assigned to the port.  A port closes unexpectively if the driver sees an end character or the control lines indicate a end.  Make sue you aren't connected to the 5V pin of the connector.  I said the simple test is to remove the cable from the device and see if it still crashes.  If you can't get to the cable then change the Port to an unused serial port and see what happens.  I fixed two similar problems like this at my company and both solutions where hardware related and not software.

    jdweng

    Thursday, June 13, 2013 9:47 AM
  • Baud=9600 both hypertrm and my app.
    hypertrm.exe = timestamped  at August 4, 2005, 13:00:00, size = 28160 bytes.
    I think this is 32 bits because it is taken from older XP and just copied into windows 8 x64 and the older XP is probably x86, didn't even know of any 64 bits version (why does it matter, it works just fine when hypertrm reads the port instead of my C#/.net app ?)
    Part of my code, just prior to Open and ReadByte (note handshake):

    port.BaudRate = 9600;
    port.Parity = Parity.None;
    port.StopBits = StopBits.One;
    port.Handshake = Handshake.None;
    port.ReadTimeout = SerialPort.InfiniteTimeout; // = -1

    I am not sure if we talk about same kind of device, my case is a PC (executing my app) with an USB port where I connect the ST-Lab which then offers a male 9 pins dsub connector at the opposite cable end which in turn is connected to a standard DCE device with straight (modem) cable.
    If the DCE device is connected to ST-Lab or not does not matter, my app crashes anyway, but if it is connected and the DCE device is sending bytes more or less continuously then it seems to be ok.
    If I remove the ST-Lab, then the virtual comm port disappears.
    Is this similar to what you have in mind too ?
    The pins 3 (Tx), 4 (DTR) and 7 (RTS) are all approx. -6.3 Volt, other pins are 0 Volt.
    This is when no DCE device is connected.

    EDIT:
    Wrapping the ReadByte into a try/catch shows that the IOExceptions are generated consistently at 250 ms after ReadByte is called.
    All the time the port.ReadTimeout has been set to -1, setting a timeout, e.g. 100 ms gives other exceptions, namely TimeoutException, but the timeout is not 100 ms, but rather 250 ms and this is independent of the setting, even 10000 ms times out after 250 ms, the only setting with effect is -1 which generates IOException instead (as explained above).
    Using physical/real comm port makes all sensible (timeouts follows the setting and IOException are not generated).

    It seems to me that the driver from Prolific is quite buggy (?)

    Thursday, June 13, 2013 12:58 PM
  • I was concerned with the your application working in 32 bit  vs 64 bit mode.  The reason the hyperterminal is working is it is using 32 bit mode.  You can set your VS application to x86 mode and see if this work.  I suspect it will.

    I'm not sure why removing the device is causing the virtual port to disappear.  It is an indication that it is using a control line.  Also verify with the hyterminal what default settings it is using (controls and handshaking) and set you application the same as the hyperterminal.


    jdweng

    Thursday, June 13, 2013 1:10 PM
  • I have 3 assemblies involved, changed all to Platform target = x86 makes no change, same problem,

    All settings are same as hypertrm.
    Removing the ST-lab device (while port is not open in my app) removes the virtual comm port from e.g. devicemanager (removing the DCE device on the other end of the ST-lab cable does not remove the port of course).
    I believe this is standard behaviour, just like other pnp usb stuff e.g. memory sticks, printers etc.

    Do you have any idea regarding the, more than a little weird, timeout behaviour described in my previous post ?

    Thursday, June 13, 2013 1:33 PM
  • "It seems to me that the driver from Prolific is quite buggy (?)"

    Works fine on Win7 with Microsoft GPS.

    Thursday, June 13, 2013 2:32 PM
  • What is MS GPS ?

    anyway, works fine here too, using cheap gps receiver. I will try to access that by SerialPort, dont know how to increase pauses to more than 250 ms though, perhaps some setting to gps.

    will update if I find out

    Thursday, June 13, 2013 2:38 PM
  • What makes you think pauses are going to fix the problem.  Normally you want to speed up the interface, not slow it down.  Maybe if I saw the entire code I could fix the problem.  It may be your code is reading the interface to slow.  You need to use a receive data event.   I've ben working with serail ports for over 30 years on PC and find the only reliable method of using the serial ports is to use a receive envent.

    jdweng

    Thursday, June 13, 2013 2:43 PM
  • Ok, you misunderstand my intention.
    Intention by slowing down was to see if the problem would occur then.
    Now I have made another program (actually just another thread in the same program) which writes test data cyclically, namely DateTime.Now.ToString(), of course to another (and physical com port, the only one I have on my PC). This port is then connected by a null-modem cable (crossed pin 2/3) to the ST-lab device.

    My listener program (the crashing one) works like a charm as long as the writer "pumps" values, if I introduce the mentioned delay, problems occur.
    A delay of 200 ms is ok, 250 ms as well, but at approx. 275 ms the problems comes up again.
    When receiving port (usb virtual) has a ReadTimeout of -1 the exception is IOException (as explained earlier), another timeout value gives TimeoutException (but the time spent until exception is always 250 ms regardless of setting).
    One should expect the reader to be ok with a Timeout setting of 500 ms if writer has pauses of 275 ms, but no, TimeoutExceptions are generated what so ever (except at setting = -1 which generates IOException, but this is also tied to the same mysterious 250 ms timespan).

    The product I want to make needs to sit and wait for bytes for perhaps long time, seconds, minutes, even hours, which means that the timeout setting must be infinitely (which is -1 or the static property SerialPort.InfiniteTimeout).

    Microsoft: Please explain why the strange timeout behaviour !!!
    It seems now like this behavior is a combination of the usb virtual port and the use of .net SerialPort (it behaves like expected with physical port and .net SerialPort)

    Yes, I could use DataReceived event, however my experience earlier (probably with physical comm ports) has been that a reader thread with blocking ReadByte was found far more reliable (I suspected things like entering event handler while still executing from earlier event etc. lots of strange behavior).
    Tested right now with events, working ok even with long pauses on the port, anyway, I thing the responsible part (Prolific ? Microsoft ?) should do something about this, after all the blocking read interface is there to be used, else it should be removed if it is not reliable in cases like this.
    Other people could be spared for frustration, I have wasted many hours already

    B.t.w. For this last testing I used port.ReadLine() instead of ReadByte(), the weird timeout behavior is the same anyway.

    Thursday, June 13, 2013 3:21 PM
  • "I thing the responsible part (Prolific ? Microsoft ?) should do something about this"

    Post a project that reproduces your problem to your SkyDrive.  I can't reproduce the problem on Win7 with a Prolific USB-to-serial comm port.  You also can't reproduce the problem with hyperterm .

    Thursday, June 13, 2013 3:41 PM
  • Serial ports work best with no delays, and using read event.  Ignore what ever you r read any place else.  I'm an expert on using serial ports.  When people have problems when using read events when there master/slave communications are wrong.  Believe me.  You must follow the protocol below.  It is fool proof and will always work.

    Client - Master                                                       Server - Slave

    ---------------------------------------------------------------------------------------------------------------------

                                                                                   Start first waiting for data

    Send command follow by CR  ---------------------->  Read command until CR is reached

                                                                                  Process command

    Read response until CR is reached <--------------  Send response followed by CR

    Send command follow by CR  ---------------------->  Read command until CR is reached

                                                                                  Process command

    Read response until CR is reached <--------------  Send response followed by CR

     

    Send command follow by CR  ---------------------->  Read command until CR is reached

                                                                                  Process command

    Read response until CR is reached <--------------  Send response followed by CR

     


    jdweng

    Thursday, June 13, 2013 5:18 PM
  • Thanks for your protocol handling scheme jdweng, however protocol may be designed in other ways and not always in our control, sometimes an old protocol has to be implemented, e.g. Modbus RTU(http://www.modbus.org/docs/PI_MBUS_300.pdf)
    This is not ASCII, but binary and with specified timeouts etc. and other silly things.

    Quick and dirty project should be on Skydrive, called ForForum
    Change portname according to your need.

    B.t.w. I just saw this thread:

    http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/dc8f858c-8f6f-4184-aac6-02ac88dc5e77

    seems to be more or less the exact same problem (without any solution though)


    • Edited by EuroEager Thursday, June 13, 2013 5:36 PM
    Thursday, June 13, 2013 5:21 PM
  • Quick and dirty project should be on Skydrive, called ForForum
    Change portname according to your need.

    B.t.w. I just saw this thread: http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/dc8f858c-8f6f-4184-aac6-02ac88dc5e77
    It
    seems to be more or less the exact same problem (without any solution though)


    Bad link.
    Thursday, June 13, 2013 5:30 PM
  • Sorry for that, link corrected, post edited
    Thursday, June 13, 2013 6:35 PM
  • Tried the same (project on my skydrive) on Windows 7 (x64), exactly same problem.

    EDIT: Same problem finally confirmed to occur also on Windows 7, x86

    • Edited by EuroEager Friday, June 14, 2013 9:34 AM
    Friday, June 14, 2013 7:33 AM
  • Hi Euro,

    I moved this thread to BCL forum for more responses.

    Thanks.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, June 17, 2013 9:36 AM
    Moderator
  • Thanks Mike

    In the meanwhile I have tried another device, similar to ST-Lab, this time an old ATEN UC232A which use driver file ser2at64.sys instead of the prolific which is  ser2pl64.sys (I am still on Windows 8/64).

    The ATEN device works exactly like expected regarding timeout etc. (i.e. just like MS own serial.sys driver for real/physicall com ports).

    My conclusion is that the Prolific driver does not respect the timeout settings at all ant acts weird if waiting 250 ms for data. ATEN will by my first choice from now (if they are manufactured).

    Monday, June 17, 2013 11:24 AM
  • "My conclusion is that the Prolific driver does not respect the timeout settings at all"

    Why would this only occur for you?

    Monday, June 17, 2013 12:30 PM
  • I wish I could answer, I have tried with 3 different PC's (2* W8/64 and one W7/32) and 2 different ST-lab cables, all show same problems.

    Do you have the same version of ser2pl64.sys (or perhaps ser2pl.sys if 32 bit OS) ? I use 3.4.48.272 (mentioned in first post).

    But, I am not alone after all, did you check my (corrected) link above ? and repeated below.

    http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/dc8f858c-8f6f-4184-aac6-02ac88dc5e77

    Monday, June 17, 2013 2:04 PM
  • MVPs?

    Ghost,
    Call me ghost for short, Thanks
    To get the better answer, it should be a better question.

    Monday, June 24, 2013 2:37 PM
  • Tried again after several updates, now the driver (ser2pl64.sys) version = 3.4.62.293.
    Problem disappeared :)
    (And I still believe I was not alone having this problem)

    Only tested on Windows 8.1, will test on Windows 7 soon...

    • Marked as answer by EuroEager Tuesday, November 5, 2013 2:51 PM
    Tuesday, November 5, 2013 1:55 PM