• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 102 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TL16C752D: Questions about interrupt operation.

Kazuya Nakai59
Guru 21675 points
Part Number: TL16C752D


Tool/software:

Hello guys,

One of my customers is evaluating TL16C752D.

At this moment, they have the following question.
Could you please give me you reply?

Q.
[Phenomenon]
When the TL16C752D was set to a faster baud rate, 115200bps and the receive trigger level was set to 4 bytes, 
and 4 bytes of data were sent from the sender, "receive timeout interrupt" occurred on the receiver
instead of "receive trigger level interrupt".
But when the baud rate was set to a slower baud rate, 1200bps, "receive trigger level interrupt" occurred under the same conditions.

[Additional information]
- At 115200bps, the actual measured time for the sender to send 4 bytes was about 300μs.
- At 115200bps, the theoretical value of the receive timeout time is about 382μs for an 8-bit word length.

It is understandable that setting the baud rate to a faster value shortens the receive timeout time,
making it easier for the receive timeout interrupt to occur.
However, even if the data transmission time is shorter than the receive timeout time,
is it expected behavior for the TL16C752D (or UART in general?) to have the receive timeout interrupt take priority
over the receive trigger level interrupt?

Your reply would be much appreciated.

Best regards,
Kazuya.

  • 0
    TI__Guru 74681 points
    Kazuya Nakai59 said:
    It is understandable that setting the baud rate to a faster value shortens the receive timeout time,
    making it easier for the receive timeout interrupt to occur.
    However, even if the data transmission time is shorter than the receive timeout time,
    is it expected behavior for the TL16C752D (or UART in general?) to have the receive timeout interrupt take priority
    over the receive trigger level interrupt?

    I think this may be because of how the internal digital circuit was designed. From what you're describing, I think the IIR bits 2 and 3 maybe OR'd to set the IIR ID. Because RX timeout and RHR interrupt both share bit2 of IIR, it probably pushes RX timeout as the priority winner since IIR bit 3 is likely OR'd. 

    This is probably because the datasheet table 4 puts RHR int (RX FIFO trigger reached) and RX timeout as both level 2 priority. 

    In both situations, you would need to read RHR to clear the INT so identifying which one occurred first becomes irrelevant. (So the designer of this device assumed it would be okay to OR these two flags together)

    -Bobby

  • 0 in reply to BOBBY
    Guru 21675 points

    Hello Bobby,

    Thank you very much for your reply.

    I told them your reply.
    They understood what you said that in both situations, you would need to read RHR to clear the INT so identifying which one occurred first becomes irrelevant.

    But they still have a question as the follows.

    Q.
    When the customer checked the operation of the TL16C752D in detail, they found that when an unexpected receive timeout interrupt occurred at 115,200 bps, the number of bytes of data set in the receive trigger level was received, just as when a receive trigger level interrupt occurred. This was the same even when the receive trigger level was set to 8 or higher. They also confirmed that the timing of the receive interrupt was clearly different from when 3 bytes were sent and received at receive trigger level 4 (the original timeout condition). A diagram was created based on the results of this check, so please take a look.
    Even in this case, could it be that the receive timeout takes priority due to the OR operation?

    They made some figures for phenomenon explanation.

    Could you please take a look the attached file and please give me your reply?

    Thank you again and best regards,
    Kazuya.

    TL16C752D_Phenomenon.pdf

  • 0 in reply to Kazuya Nakai59
    TI__Guru 74681 points
    Kazuya Nakai59 said:
    Even in this case, could it be that the receive timeout takes priority due to the OR operation?

    Yes, I do think that the RX timeout takes priority due to the Or condition (because the RXRDY state also ors these two flags to generate an interrupt so you can't use this pin to differentiate them either).

    My guess is that the processor takes some time to read the IIR register. By the time it actually reads it, the RX timeout may have already occurred and will overwrite the RX trigger identifier with an RX timeout. 

    I think if the processor could read the IIR fast enough, it might be able to see the RX trigger identifier before it gets overwritten.

    -Bobby

  • 0 in reply to BOBBY
    Guru 21675 points

    Hello Bobby,

    Thank you very much for your strong supports.

    They understood your reply.

    I'll check the box of "Resolved".

    Thank you again and best regards,
    Kazuya.