This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001483] New: Generic 16x5x driver has incorrect errorprocessing


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001483

           Summary: Generic 16x5x driver has incorrect error processing
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Other
            Status: UNCONFIRMED
          Severity: normal
          Priority: low
         Component: Serial
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: bernard.fouche@kuantic.com
                CC: ecos-bugs@ecos.sourceware.org
             Class: Advice Request


Reading 16550D datasheet and DSR code shows a potential bug:

- DSR reads IIR to discover what job to do, does the job, re-read IIR, etc. For
instance DSR reads IIR and sees a RX/RxTimeout interrupt, so it reads LSR until
the RX FIFO is empty. Or DSR reads IIR and sees a Receiver Line Status (RLS)
interrupt and then it processes the different possible errors (Overrun, Parity,
Frame, Break) by reading LSR.

The issue is that both processing (Rx/RxTimeout and error) require reading LSR.
However LSR may have different bits set a the same time, and they are reset as
soon as LSR is read. So if LSR is read to empty the RX FIFO, a bit showing an
error will be reset. When RLS processing is triggered it won't find any error
bit set in LSR.

This is accentuated by:

- Parity, Frame and Break errors are reported in LSR for the byte AT THE TOP of
the FIFO hence correct processing of these error must be done when emptying the
FIFO: once the FIFO is emptied, these bits won't be set anymore. Datasheet
excerpts:

"Bit 2: This bit is the Parity Error (PE) indicator... [snip]... This error is
revealed to the CPU when its associated character is at the top of the FIFO."

Bit 3: This bit is the Framing Error (FE) indicator...[snip]... This error is
revealed to the CPU when its associated character is at the top of the
FIFO.[snip]

Bit 4: This bit is the Break Interrupt (BI) indicator. This error is revealed
to the CPU when its associated character is at the top of the FIFO.[snip]"

- However overrun error shows up at anytime, immediately when it occurs. Again,
as soon as LSR is read, overrun error information is lost.

(FYI, LPC17XX datasheet describes the same behavior)

The consequence is that the code emptying the RX FIFO just discards all error
related information when it runs. The only chance for the driver to grab an
error is, since the error interrupt condition has the highest priority, is the
overrun error, or if a single byte is available in the FIFO when the DSR runs
and this byte has error bits attached to it.

The fix should be to merge RX FIFO emptying and error processing, more exactly
to have a single piece of code that reads LSR and each time LSR is read the
whole set of error condition is checked.

BTW I gave a look at the 16550 Linux serial driver and as far as I understand
it, when LSR is read all error conditions are processed per byte extracted from
the FIFO (but Overrun Error that has special processing). IMHO this confirms
that the current processing done by eCos has the reported issue.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]