Lpc2000

I was wondering if anyone has seen the errata on the UART in terms of 
the hardware race condition that Robert pointed out many posts ago.  
Also, I was wondering if the read-the-IIR-once-and-only-once solution 
is the workaround.  The errata states that reading the IIR will only 
clear the THRE interrupt on UART1, however, the user's manual states 
otherwise.  I'm waiting to hear back from a Philips FAE on this.

Thanks,

John

Quoting johnthomasedwardtimm <area51@...>:

> I was wondering if anyone has seen the errata on the UART in terms of
> the hardware race condition that Robert pointed out many posts ago.
> Also, I was wondering if the read-the-IIR-once-and-only-once solution
> is the workaround.  The errata states that reading the IIR will only
> clear the THRE interrupt on UART1, however, the user's manual states
> otherwise.  I'm waiting to hear back from a Philips FAE on this.

It appears that this is taken care of by turning the FIFOs on.  I suspect that
with the FIFOs off there is a race condition but I suspect all we'll ever know
is that we have to turn the FOFOs on.  Reading the IIR only once per interrupt
does mask it somewhat but someone reported still missing interrupts in that
case (I'd credit the reporter but I'm away from my notes, my 
apologies). Turning on the FIFO has eliminated the problem , at least 
so far.  And there is
a one line note in the UM stating that the FIFO must be turned on.

Robert

We are experiencing the same problem as your in your message, our 
code is structured similarily to yours, and we have the FIFO turned 
on.  Changing our "while" loop to an "if" statement, as you did, has 
alleviated the problem.  The errata states that if MSR interrupt is 
turned off, which it is in our case, then the THRE interrupt is 
lowest priority.  We only have two interrupts configured THRE and 
RDA.  As per the errata, if we read the IIR and it is a THRE, we are 
okay in that it won't clear a pending RDA that occurs during the 
read.  If we read the IIR and it is an RDA we should get the RDA and 
a pending THRE will come in as a separate interrupt because reading 
the RDA is non-destructive.  When using the "while" loop we are 
reading multiple times possibly clearing a THRE interrupt 
inadvertantly when reading second time after RDA to check for 
additional interrupts.  It appears, that as per the "workaround" in 
the errata and the example code that philips generated themselves, 
the read-the-IIR-once-and-only-once method you came up with seems 
like a realistic workaround to the problem.  Obviously we need more 
testing but we were getting it to fail every 10 minutes or so.  It 
has now run for hours and we intend to run it all weekend with heavy 
data traffic in both directions.

John


--- In lpc2000@...m, Robert Adsett <subscriptions@...> 
wrote:
>
> Quoting johnthomasedwardtimm <area51@...>:
> 
> > I was wondering if anyone has seen the errata on the UART in 
terms of
> > the hardware race condition that Robert pointed out many posts 
ago.
> > Also, I was wondering if the read-the-IIR-once-and-only-once 
solution
> > is the workaround.  The errata states that reading the IIR will 
only
> > clear the THRE interrupt on UART1, however, the user's manual 
states
> > otherwise.  I'm waiting to hear back from a Philips FAE on this.
> 
> It appears that this is taken care of by turning the FIFOs on.  I 
suspect that
> with the FIFOs off there is a race condition but I suspect all 
we'll ever know
> is that we have to turn the FOFOs on.  Reading the IIR only once 
per interrupt
> does mask it somewhat but someone reported still missing 
interrupts in that
> case (I'd credit the reporter but I'm away from my notes, my 
> apologies). Turning on the FIFO has eliminated the problem , at 
least 

> so far.  And there is
> a one line note in the UM stating that the FIFO must be turned on.
> 
> Robert
>

At 05:45 AM 4/22/06 +0000, johnthomasedwardtimm wrote:
>We are experiencing the same problem as your in your message, our
>code is structured similarily to yours, and we have the FIFO turned
>on.  Changing our "while" loop to an "if" statement, as you did, has
>alleviated the problem.  The errata states that if MSR interrupt is
>turned off, which it is in our case, then the THRE interrupt is
>lowest priority.  We only have two interrupts configured THRE and
>RDA.  As per the errata, if we read the IIR and it is a THRE, we are
>okay in that it won't clear a pending RDA that occurs during the
>read.  If we read the IIR and it is an RDA we should get the RDA and
>a pending THRE will come in as a separate interrupt because reading
>the RDA is non-destructive.  When using the "while" loop we are
>reading multiple times possibly clearing a THRE interrupt
>inadvertantly when reading second time after RDA to check for
>additional interrupts.  It appears, that as per the "workaround" in
>the errata and the example code that philips generated themselves,
>the read-the-IIR-once-and-only-once method you came up with seems
>like a realistic workaround to the problem.  Obviously we need more
>testing but we were getting it to fail every 10 minutes or so.  It
>has now run for hours and we intend to run it all weekend with heavy
>data traffic in both directions.

Interesting, it sounds like something more than just a FIFO bug is going 
on.  What errata are you referring to?  I don't remember a serial port 
errata but I may have missed it.  The only tests I'm aware of are like 
yours, heavy data traffic.  That gets some idea of probability but I'd like 
to get something more definitive.  Without a better idea of the root cause 
though I'm not sure what to try.

If you hear back from Philips let us know please.  I'd like to get a better 
handle on this.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, "johnthomasedwardtimm" <area51@...> wrote:
>
> The errata states that if MSR interrupt is 
> turned off, which it is in our case, then the THRE interrupt is 
> lowest priority.  We only have two interrupts configured THRE and 
> RDA.  As per the errata, if we read the IIR and it is a THRE, we are 
> okay in that it won't clear a pending RDA that occurs during the 
> read.  If we read the IIR and it is an RDA we should get the RDA and 
> a pending THRE will come in as a separate interrupt because reading 
> the RDA is non-destructive.

Have a look UART.1 errata for LPC2292.  The errata does not identify
the root cause and thus it is difficult to say if and how this could
manifest in your particular scenario.

Also have a look at the interaction of RDA with CTI signals that is
covered by AN10414.

I suspect your answer lies somewhere between the two. 

Jaya