Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

OK. I will try to be more precise with my description.

First of all, in my case I am actually looping back from one COM port
on my WinCE device to the another (with a cross serial cable).
Previously I was communicating with an external machine (which was
when I noticed the problem). I have switched to looping back onto
myself so I have more control of the comms.

So the numbers I quoted are for the % of reads that do not succeed.
That is, I output 1000 bytes on one port, then attempt to read these
1000 again on the other. 8% of the time at 19200, the full 1000 bytes
are not read (say 998 are), and I get the CommErrorEventHandler event
fired.

I don't know if it is the serial driver or the UART. What actually
happens is that within the OpenNETCF code, the
"m_CommAPI.WaitCommEvent(hPort, ref eventFlags)" call fails, and when
"m_CommAPI.ClearCommError(hPort, ref errorFlags, commStat)" is called,
errorFlags has (only) the OVERRUN bit set. This code interprets this
as a UART error.

(This code can be found at
http://www.opennetcf.org/SourceBrowse/view.aspx?f=d:/sites/OpenNETCF/InetPub/wwwroot/Source/OpenNETCF/IO/Serial/Port.cs
- about line 913 - 1011)

So I am at a bit of a loss...
It doesn't appear to be related to how fast my app reads the data - I
am basically going full speed in a tight loop. The buffers I am using
(which get passed to "m_CommAPI.SetupComm(hPort, rxBufferSize,
txBufferSize") are large - 10000 bytes.

It would seem to me that the best approach at this point is to:
a) Try and get hardware handshaking to work. The external device
supports DTR/DSR)
b) Rewrite in C (to bypass any problems with OpenNETCF/CF.NET?)


pietdesomere@xxxxxxxxx (Piet) wrote in message news:<b498cce3.0504042314.1fc30326@xxxxxxxxxxxxxxxxxx>...
> What do these percentages mean? Do you lose 8% of the bytes?
>
> Do you know if it's the UART's FIFO buffer or the Serial Driver's
> buffer that overruns? Do you have debug output from the serial driver?
>
> If it's the UART's FIFO buffer: I think you should be fast enough to
> read even at 115200, and if you are not handshaking should solve this.
> You say it makes no difference, this could mean it's not enabled on
> the other side. Can you change the settings for the thing you're
> communicating with?
>
> If it's the Serial Driver's buffer that overruns, your application is
> not reading fast enough. If you create a loop that does nothing except
> reading from the COM port, and you read say 4K at a time, and you
> still have problems the problem is probably not in your application.
>
> From your description it's most likely the UART buffer so I think you
> will need handshaking.
>
> Regards,
> Piet
>
> andrew_revell@xxxxxxxxxxx (Andrew Revell) wrote in message news:<6dd1a40b.0504041731.3f59cd91@xxxxxxxxxxxxxxxxxx>...
> > I am writing an application on the following platform:
> >
> > Advantech 133Mhz PCM3348.
> > Windows CE 5.0 (Build 1400).
> > Compact Framework
> > OpenNETCF SDF 1.2.
> >
> > What I am experiencing is within my C# code, I am occasionally getting
> > a UART: Overrun error (caught by the handler for
> > CommErrorEventHandler).
> >
> > The pattern is roughly:
> >
> > 9600 baud ? no errors (or so few I never see them).
> > 19200 baud ? errors about 8% of the time.
> > 115200 baud ? errors about 11% of the time.
> >
> > Number of errors also increases as the number of received increases.
> >
> > Along with the CommErrorEventHandler event being fired, the received
> > buffer is usually missing a char or two (out of 1000). The position of
> > the missing char is random.
> >
> > Things that do not seem to make a difference:
> > Handshaking (DSR/DTR, CTS/RTS etc)
> > Buffer sizes (I have set to 10 times maximum receive buffer).
> >
> > I have also given the "Installable ISR" serial driver a go, by putting
> > entries such as:
> > "Irq"=dword:4
> > "IsrDll"="isr16550.dll"
> > "IsrHandler"="ISRHandler"
> >
> > This _appears_ to improve matters, but not fix completely.
> >
> > I have tried this with another .Net library as well (CFSerialClass).
> > The number of errors are less, but not much.
> >
> > What I would appreciate advice on is:
> >
> > Is this a common problem when dealing with serial?
> > Are these errors just a fact of life with serial? But surely 19200
> > isn't too fast for it to handle?
> > Should I try writing direct eVC++ code? Will this help?
> > Are there settings in the Device Control Block that could help here?
> > Should I try changing serial interrupt priorities? If so, how?
> >
> > I guess I am searching for ways of narrowing this down. Is it
> > OpenNETCF, .NET, Windows CE, my hardware??.?
.

Relevant Pages

  • [PATCH] cpm_uart: Fix dpram allocation and non-console uarts
    ... Makes non-console UART work on both 8xx and 82xx ... static unsigned int cpm_uart_tx_empty(struct uart_port *port) ... /* Write back buffer pointer */ ... * Allocate DP-Ram and memory buffers. ...
    (Linux-Kernel)
  • Re: How to avoid serial port buffer overruns?
    ... port buffer overruns quite easily if I use a baudrate high enough (I start ... the way to avoid overruns on a serial port was to use ... a buffered serial port UART. ...
    (Linux-Kernel)
  • Re: Thorny Serial Comms "UART: Overrun" error Windows CE 5.0
    ... I think patching the serial driver should be a near to last ... - Parallel port. ... >> errorFlags has the OVERRUN bit set. ... >>> Do you know if it's the UART's FIFO buffer or the Serial Driver's ...
    (microsoft.public.windowsce.platbuilder)
  • Re: interthread communication
    ... Since this is a writer thread, typically you will PostThreadMessage to it for each packet ... Note that if you have a serial port you must open it for asynchronous I/O. ... of the buffer in via a PostThreadMessage, so using a single variable cannot make sense. ...
    (microsoft.public.vc.mfc)
  • Re: Highly responsive serial port
    ... My problem consists of reading from a serial COM port as fluent as possible. ... If my reader only reads the input buffer after 50ms I'm too late to reply but I don't know it. ... Would a driver(in kernel mode) have enough priority to process such requests in time? ... a general rule of thumb in thread synchronization is to stay away from depending on "sleep" and loop designs in a vain attempt to synchronize I/O. ...
    (microsoft.public.win32.programmer.kernel)