TL16C752D: Has the TL16C752B/754B errata been fixed in the TL16C752D?

Hi Kazuya,

I'll try to get back to you on this by the end of the week. 

-Bobby

Hi Bobby,

Thank you very much for your reply.

I see. I'll wait for your update.

Thank you again and best regards,
Kazuya.

Hi Bobby,

Could you please give me your progress?

Thank you again and best regards,
Kazuya.

Hi Kazuya,

Sorry I didn't get back to you last week. 

I'm still trying to work with the design engineer for the D version of this device. 

But I can provide what I think:

Kazuya Nakai59 said:

1. Has this TL16C752B/754B errata been fixed in the TL16C752D and TL16C754C?

This is what I'm trying to clarify with designer now.

Kazuya Nakai59 said:

2. What is the value read from the IIR when the errata phenomenon occurs? Is it IIR[5:0] 0x01?

I think you should read the time out code unless the RHR threshold is met. 

Kazuya Nakai59 said:

3. If it is difficult to implement the "Work Around: Read only the IIR that corresponds
    to the channel that generated the interrupt", are there any other workarounds?

I also think if you set the RX trigger threshold and use the IIR to look for the RHR interrupt, then you can still work around the issue by keeping the INT latched when the RHR interrupt occurs. 

-Bobby

Hi Kazuya,

The designer got back to me and he doesn't think the errata that was in B for what you're asking about was fixed as he thinks this is expected behavior. 

-Bobby

Hi Bobby,

Thank you very much for your checking.

Please let me confirm.

My understanding is that the errata has not been fixed. Is my understanding correct?

Thank you again and best regards,
Kazuya.  

Hi Bobby,

Thank you very much for your strong supports.

Please let me confirm again about Q1 and could you give me your answer to Q2 and Q3?

About Q1.
Again, is the following my understanding correct to the customer No.1 question?
(Customer question No.1: TL16C752B/754B errata been fixed in the TL16C752D and TL16C754C?)

My understanding: The errata of the TL16C752B was recognized as expected behavior by TI and has not been fixed.

About Q2.
You replied for their question No.2 was that I think you should read the time out code unless the RHR threshold is met.
Could you tell me the mean of "RHR threshold"?

What is the action if RHR threshold is met?

Is the value read from the IIR when the errata phenomenon occurs unknown? Is it not IIR[5:0] 0x01?

About Q3.

You answered to Q3 that I also think if you set the RX trigger threshold and use the IIR to look for the RHR interrupt, then you can still work around the issue by keeping the INT latched when the RHR interrupt occurs.

Could you please give me how to keep the INT latched when the RHR interrupt occurs?

Thank you again and best regards,
Kazuya.

Kazuya Nakai59 said:

Could you tell me the mean of "RHR threshold"?

What is the action if RHR threshold is met?

IIR = 000100 and RXRDY goes low, you would need to wait for this to occur to see the interrupt 

Kazuya Nakai59 said:

Is the value read from the IIR when the errata phenomenon occurs unknown? Is it not IIR[5:0] 0x01?

Yes, you would see 0x01 since an interrupt isn't there. 

You could read LSR0 to see if RX data is present.

Kazuya Nakai59 said:

Could you please give me how to keep the INT latched when the RHR interrupt occurs?

This should happen when your RX trigger threshold is met which you can set in FCR 7:6. 

-Bobby

Hi Bobby,

Thank you very much for your strong supports.

Could I ask you the following questions?

Q1.
We understand that TL16C752B Errata No.3 has been not fixed on TL16C752D.
TL16C752B Errata says about No.3 "The TL16C752B 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."

The customer think that since errata No. 3 has not been fixed, the TL16C752D datasheet
should explain this phenomenon and countermeasure in the device datasheet.
But they couldn't find it.
Is that explanation written in the datasheet?

Q2.
I'm sorry again to ask you same question because I couldn't understand the countermeasure you explained.

"if you set the RX trigger threshold and use the IIR to look for the RHR interrupt,
then you can still work around the issue by keeping the INT latched when the RHR interrupt occurs."

Could you please tell me the actions I should do with step by step? 

Your reply would be much appreciated.

Thank you again and best regards,
Kazuya Nakai.

Hi Bobby,

Thank you very much for your strong supports.

The customer wants TI to answer to the following questions as additional.
Could you please reply?

Q1.
Is it possible for this erratum to occur even if an interrupt with a higher priority than the transmit interrupt, such as a receive trigger level interrupt, is occurring?

Q2.
If an IIR reading, a transmit interrupt, and a receive interrupt occur simultaneously, will the transmit interrupt be cleared?

Your reply would be much appreciated.

Thank you again and best regards,
Kazuya.

Hi Bobby,

Thank you very much for your strong supports.

I need your reply.
Could you please give me your update?

Thank you again and best regards,
Kazuya.

Hi Bobby,

Could you please give me your reply?

Or should I ask these questions on a new thread of E2E?

Thank you very much and best regards,
Kazuya

Sorry Kazuya,

Last week we had a US holiday and I've been behind on my customer support threads. 

Kazuya Nakai59 said:

Q1.
Is it possible for this erratum to occur even if an interrupt with a higher priority than the transmit interrupt, such as a receive trigger level interrupt, is occurring?

If the timeout interrupt occurs and de-asserts, the RX trigger interrupt should still be in effect. Customer can also monitor the RXRDY pin.

Kazuya Nakai59 said:

If an IIR reading, a transmit interrupt, and a receive interrupt occur simultaneously, will the transmit interrupt be cleared?

No, it should still be there. An alternative would be to look at the TXRDY pin. 

Let me know if you have additional questions. 

-Bobby

Hi Bobby,

Thank you very much for your strong supports.

Could you please answer to the following questions I sent you?

Q1.
We understand that TL16C752B Errata No.3 has been not fixed on TL16C752D.
TL16C752B Errata says about No.3 "The TL16C752B 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."

The customer think that since errata No. 3 has not been fixed, the TL16C752D datasheet
should explain this phenomenon and countermeasure in the device datasheet.
But they couldn't find it.
Is that explanation written in the datasheet?

Q2.
I'm sorry to ask you same question again. Because I couldn't understand the countermeasure you explained.

"if you set the RX trigger threshold and use the IIR to look for the RHR interrupt,
then you can still work around the issue by keeping the INT latched when the RHR interrupt occurs."

Could you please tell me the actions I should do with step by step? 

Your reply would be much appreciated.

Thank you again and best regards,
Kazuya Nakai.

Hi Bobby,

Thank you very much for your strong supports.

Could you please give me your answers?

Thank you and best regards,
Kazuya.

Kazuya Nakai59 said:

Is that explanation written in the datasheet?

No, this has not been added to the datasheet. 

Kazuya Nakai59 said:

Could you please tell me the actions I should do with step by step? 

The easiest approach is to set the RX FIFO trigger to be a lower value and check RXRDY pin to do your reads.

You can set this level by writing to TLR[7:4]

You can also read the FIFO ready register to check if the RX has hit the threshold you set in TLR.

Reading LSR0 also provides you with a way to verify if RHR has a byte in it.

You can also set the FCR[7:6] enable the IER[2] and then when a INT occurs (due to the RX FIFO threshold) you can read IIR and look for 001100 (assuming RX timeout disappears). 

You essentially have multiple ways to know when the RX FIFO threshold has been reached. 

-Bobby

Hi Bobby,

Thank you very much for your explanation. I really appreciate.

Please let me confirm.

I understand that TL16C752D still has the errata of TL16C752B as the follow.
https://www.ti.com/jp/lit/er/sllz049/sllz049.pdf

My question is the follow.

The customer wants to know any other workaround in case that it is difficult
to implement the workaround for errata No. 3: Read only the IIR that corresponds 
to the channel that generated the interrupt" in the errata report

Is your explanation,
>The easiest approach is to set the RX FIFO trigger to be a lower value and check RXRDY pin to do your reads.
>~
>You can also set the FCR[7:6] enable the IER[2] and then when a INT occurs (due to the RX FIFO threshold) you can
>read IIR and look for 001100 (assuming RX timeout disappears). 

for No.1 of TL16C752B errata not errata No.3?

If your explanation is a workaround for errata No. 1,
could you please tell me a workaround for errata No. 3?

Thank you again and best regards,
Kazuya.

Hi Bobby,

I know you are very busy.
But we need your reply to use TL16C752D.

Could you please give me your reply?

Thank you again and best regards,
Kazuya.

Kazuya Nakai59 said:

for No.1 of TL16C752B errata not errata No.3?

If your explanation is a workaround for errata No. 1,

Yes, I'm basically suggesting that instead of looking for a character timeout the customer looks for the RX FIFO limit being met. I know it's not 100% the same thing but I assume this approach would work for the ISR (though maybe less efficient). 

Kazuya Nakai59 said:

could you please tell me a workaround for errata No. 3?

Looks like there are two ways to check if TX FIFO is empty/ready for data.

You can read the LSR5 and LSR6 to see if there is data in the THR. 

You can also check TXRDY. 

-Bobby