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.