Forums

Missing THRE Interrupt

Started by johnthomasedwardtimm April 21, 2006
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

An Engineer's Guide to the LPC2100 Series

Quoting johnthomasedwardtimm :

> 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 l..., Robert Adsett
wrote:
>
> Quoting johnthomasedwardtimm :
>
> > 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 l..., "johnthomasedwardtimm" 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