Forums

LPC2468 & SC16IS752 DUART Anomaly

Started by KM Shore July 13, 2009
I am using both of these NXP parts with the DUART connected via one of the
i2c busses to the 2468. After long periods of moderate traffic (short
bursts of 20 or fewer characters, followed by a few seconds of no traffic),
the DUART will set an interrupt; the status(IIR) indicates that a stale
character is in the receive FIFO. When the DUART is queried both the LSR and
input character count (RXLVL) indicate nothing is there. Unless a read
command is executed, this interrupt will continue. A read of 1 byte will
clear the situation. It is unclear whether the character that is read is
good or not. For now we are discarding it.

Looking for anyone who has any experience with this behavior.

-Kerry

Kerry Shore

Forward Pay Systems

k...@forwardpay.com

952-941-8188 x102



An Engineer's Guide to the LPC2100 Series

I have used two SC16IS752 DUARTs in SPI mode (with a LPC2148) and I
don't believe I have seen your issue.
Since the SPI/IIC bus is a shared resource I poll the interrupt line of
the Duarts rather than use an interrupt line as there is nothing to be
gained from using an ISR, but this should make no difference.
If you like you can look/compare at my driver called spi_uart as part of
newlib_lpc.

Cheers,
Bruce
-----Original Message-----
From: l... [mailto:l...] On Behalf
Of KM Shore
Sent: Tuesday, 14 July 2009 2:20 AM
To: l...
Subject: [lpc2000] LPC2468 & SC16IS752 DUART Anomaly

I am using both of these NXP parts with the DUART connected via one of
the
i2c busses to the 2468. After long periods of moderate traffic (short
bursts of 20 or fewer characters, followed by a few seconds of no
traffic),
the DUART will set an interrupt; the status(IIR) indicates that a stale
character is in the receive FIFO. When the DUART is queried both the LSR
and
input character count (RXLVL) indicate nothing is there. Unless a read
command is executed, this interrupt will continue. A read of 1 byte will
clear the situation. It is unclear whether the character that is read
is
good or not. For now we are discarding it.

Looking for anyone who has any experience with this behavior.

-Kerry

Kerry Shore

Forward Pay Systems

k...@forwardpay.com

952-941-8188 x102



FYI, since posting my question we received a response from NXP (Something
for your toolbox):

NXP Semiconductors answer:
Hi Eric,
thanks for putting this in the tech support & sorry for the delay- I got an
answer back from the Engineer today.

So I am not 100% clear of the exact mechanism of what is happening but the
issue has something to do with the interrupt synchronization - the device
will generate a bogus interrupt when a read of the IIR register occurs when
this register is being updated. The way to solve this issue is to do a read
of the receive FIFO and throw away the character since this is a bogus
character. If there is a 'good' character, it will be reflected by the LSR
register bit 0 on subsequence read of the LSR register.

So there is a work around as it seems you already know

From: l... [mailto:l...] On Behalf Of
Bruce Paterson
Sent: Monday, July 13, 2009 7:36 PM
To: l...
Subject: RE: [lpc2000] LPC2468 & SC16IS752 DUART Anomaly

I have used two SC16IS752 DUARTs in SPI mode (with a LPC2148) and I
don't believe I have seen your issue.
Since the SPI/IIC bus is a shared resource I poll the interrupt line of
the Duarts rather than use an interrupt line as there is nothing to be
gained from using an ISR, but this should make no difference.
If you like you can look/compare at my driver called spi_uart as part of
newlib_lpc.

Cheers,
Bruce
-----Original Message-----
From: l...
[mailto:l... ] On
Behalf
Of KM Shore
Sent: Tuesday, 14 July 2009 2:20 AM
To: l...
Subject: [lpc2000] LPC2468 & SC16IS752 DUART Anomaly

I am using both of these NXP parts with the DUART connected via one of
the
i2c busses to the 2468. After long periods of moderate traffic (short
bursts of 20 or fewer characters, followed by a few seconds of no
traffic),
the DUART will set an interrupt; the status(IIR) indicates that a stale
character is in the receive FIFO. When the DUART is queried both the LSR
and
input character count (RXLVL) indicate nothing is there. Unless a read
command is executed, this interrupt will continue. A read of 1 byte will
clear the situation. It is unclear whether the character that is read
is
good or not. For now we are discarding it.

Looking for anyone who has any experience with this behavior.

-Kerry

Kerry Shore

Forward Pay Systems

k...@forwardpay.com

952-941-8188 x102