TL16C2550: Behavior Inconsistent with the Datasheet

Hi Ethan White,

Thank you for your answer.

Please let me know if you find out anything about Q2.

Best Regards,

ttd

Hi Ethan White,

We have conducted additional verification regarding this matter and are writing to inform you of the results and the items we would like you to re-verify.

[Results of Additional Verification]

Regarding the “inconsistency between Data Ready and the receive interrupt status” we previously reported, we observed the following conditions during transmission and reception tests using the return fixture:

・Receive Interrupt: Active

・IIR: 0xCC (Character Timeout Indication)

・LSR: 0x60 (Data Ready = 0)

・RXRDY: Low (Active)

Normally, the RBR is not read when Data Ready = 0. However, when we read the RBR under the above conditions regardless of the Data Ready value, we were able to

successfully retrieve the received data.

Based on these results, we believe it is highly likely that, even though valid data actually exists in the RX FIFO, the LSR’s Data Ready is indicating 0.

[Items to Be Reconfirmed]

We apologize for the inconvenience, but could you please confirm the following with TI regarding the phenomenon described above?

1. TI’s Recognition of the Phenomenon

Regarding the phenomenon where “the LSR’s Data Ready indicates 0 even though valid data exists in the RX FIFO,” is this recognized by TI as a known defect or a known

phenomenon?

2. Existence of Errata and Known Issues

Regarding the TL16C2550IPFB, are there any published or internal errata, known issues, or usage precautions related to the phenomenon described above?

Additionally, if no errata have been issued at this time, please confirm whether there are plans to issue any in the future.

3. Recommended Workaround

Is the method you described—“writing a 1 to bit 1 of the FCR and resetting the RX FIFO”—an official workaround recommended by TI?

I understand that resetting the RX FIFO erases any unread data within the FIFO. Therefore, please advise on any recommended procedures

or alternative workarounds for processing received data without losing it.

4. Applicability to the TL16C752D

Our company plans to adopt the TL16C752D for another product. Regarding the TL16C752D, please confirm once again whether please reconfirm whether the phenomenon where “Data

Ready becomes 0 even though data exists in the RX FIFO” is recognized as a known issue for the TL16C752D.

Additionally, please let us know if there are any errata, known issues, or recommended workarounds for this product.

If necessary, we can provide the register values, bus access waveforms, and observed waveforms for INT and RXRDY that we have captured.

Best Regards,

ttd

Hi Hi Ethan White,

Regarding this matter, we have attached the following four documents used to verify the phenomenon.

We provide the following supplementary information regarding the contents of each document.

See attached files.

Files for TL16C2550.zip

[Attached Documents]

■ Diagram.png

This document illustrates the configuration using the TL16C2550.

The configuration converts PCIe access requests issued by the CPU into local bus access via the FPGA,

and accesses two TL16C2550 devices.

We are using two TL16C2550 devices, each configuring 2 channels, for a total of 4 UART channels.

For each channel, we connected a fixture that loops the transmit signal back to the receive signal and conducted tests involving repeated transmission and reception.

■ 260813_iirCC8k_v2.ila

This is the Vivado ILA data that served as the basis for “ScreenShot-260813_iirCC8k_v2.png,” described below.

It can be viewed in Vivado 2023.2 or later.

If necessary, we can also provide the data in CSV format.

■ ScreenShot-260813_iirCC8k_v2.png

This is the ILA waveform captured when it was confirmed that the “Data Ready” state did not match the actual receive FIFO state.

Below is a description of the main signals:

・adr_n_out[7:0]

This signal combines device selection, Chip Select, and register address, and

* bit[4]: Device selection

* bit[3]: Chip Select selection

* bit[2:0]: TL16C2550 register address

・data_in_0–3

Since the CPU’s PCIe access is 32 bits wide, the read data is split into 8-bit segments for observation.

The correspondence with the 32-bit data is as follows:

[31:0] = {data_in_3[7:0], data_in_2[7:0], data_in_1[7:0], data_in_0[7:0]}

.

In this waveform, the relevant data_in_1 and data_in_2 signals are displayed.

・SIO_A(B)_RXRDY1(2)_N_IBUF

This is the RXRDY output signal of the TL16C2550.

On the waveform display, it corresponds to CH1, CH2, CH3, and CH4, in that order from top to bottom.

In this waveform, the phenomenon is occurring on CH4.

[Operation on the Waveform]

At the trigger point (around 100 pt),

adr_n_out = 0x1A,

and it is reading the CH4 IIR (Register Address = 2).

At this point,

IIR = 0xCC

is read from the TL16C2550, confirming that a Character Timeout Indication has occurred.

Subsequently, at the yellow cursor position (around 2,061 pt),

adr_n_out = 0x1D

indicating that the LSR (Register Address = 5) of CH4 is being read.

At this point,

LSR = 0x60

is read.

Therefore,

LSR[0] Data Ready = 0

.

Note that there are two write accesses near 1,000 pt;

however, both are accesses to the IER (Register Address = 1)

and do not directly affect the presence or absence of data in the receive FIFO being examined here.

Furthermore, during this period, CH4’s RXRDY remains continuously Low (Active).

Therefore, in this waveform,

* IIR = 0xCC (Character Timeout Indication)

* RXRDY = Low (Active)

* LSR = 0x60 (Data Ready = 0)

are observed simultaneously.

■ log_DataReady-Error_260903.txt

This is the operation log acquired on the CPU side.

It is a log recorded when a timeout occurred in the reception processing within the program during a test involving repeated transmission and reception.

This event occurred on CH3 (/ttyS6), and when IIR, LSR, and RBR were read for debugging purposes at the time of the timeout,

IIR = 0xCC

LSR = 0x60

RBR = 0x42

were confirmed.

In other words,

* IIR indicates a Character Timeout

* LSR indicates Data Ready = 0

* However, when RBR is actually read, valid received data (0x42) can be successfully retrieved

This is the state observed.

Based on these results, we have determined that, at least at the time this issue occurred, valid data was present in the receive FIFO,

yet only the LSR’s Data Ready was showing a value of 0.

Furthermore, we have observed a similar phenomenon on CH4 in the ILA waveform and on CH3 in the CPU log,

and therefore believe this is not a phenomenon limited to a specific UART channel.

If there is any additional information required, or any signals, registers, etc., that need to be verified,
we will obtain them to the extent possible, so we would appreciate it if you could contact us.

Best Regards,

ttd