Lpc2000

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
>