Part Number: AM3352
Other Parts Discussed in Thread: TL16C754B
Hello,
BACKGROUND:
My name is Everett Sykes. I'm a design engineer for Western Telematic, Inc. (WTI). We make a line of products that use a CPU board based on the Beagle Bone Black. Our board uses a AM3352 ARM processor. We're using an older version of Linux (V5.4) that was provided to us by TI.
OUR CONFIGURATION:
Our board uses a number of QUAD UARTS. We have all the interrupts running through open gate inverters which are wire-ored into a single interrupt going into the processor. We recently switched from an EXAR part to the TI TL16CP754C part. Since the switch we notice, when stressing the UARTs, that the unit hangs up. We determined that the code is stuck in the interrupt service routine, continually reading the IIR.
We found an errata (SLLZ048) that lists several known problems with this QUART. One of them seems to match our problem. I've tried reading the LSR, before reading the IIR, to determine if there is an interrupt before clearing it by reading the IIR. But this just leads to the unit missing the interrupt and defaulting to polling mode.
ERRATA (SLLZ048):
3. Problem: The TL16C754B can clear the just set THRE interrupt condition if the IIR read is coincident to the
THRE setting. Since IIR reads are generally asynchronous with respect to the THRE setting, the possibility
exists for this problem to occur, although it is unlikely. Reading the IIR is one of the normal clearing
mechanisms for the THRE interrupt. Most software will read the IIR only as a response to assertion of the INT
pin, which means that this overlap cannot occur. This problem is seen only on systems that logically OR the
four individual INTA,B,C, and D signals into one signal to the uP. In detecting which channel had the interrupt,
it is necessary to read all four channel's IIRs, and this is when the overlap can occur.
Work Around: Read only the IIR that corresponds to the channel that generated the interrupt.
Severity: Minor
QUESTIONS:
1. Have you heard of this problem?
2. So you have any suggestions to prevent this interrupt lockup from happening?
