This is the mail archive of the
ecos-bugs@sourceware.org
mailing list for the eCos project.
[Bug 1001483] New: Generic 16x5x driver has incorrect errorprocessing
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Sat, 11 Feb 2012 14:06:00 +0000
- Subject: [Bug 1001483] New: Generic 16x5x driver has incorrect errorprocessing
- Auto-submitted: auto-generated
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.