• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 31 subscribers
  • Views 12168 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.

UART Receive Timeout

Timothy Ball
Expert 1175 points
Other Parts Discussed in Thread: TM4C129DNCZAD, TM4C1290NCZAD

The Tiva TM4C129DNCZAD Microcontroller DATA SHEET includes the following paragraph in section 19.3.9 for UART Interrupts:

 

“The receive timeout interrupt is asserted when the receive FIFO is not empty, and no further data

is received over a 32-bit period when the HSE bit is clear or over a 64-bit period when the HSE bit

is set. The receive timeout interrupt is cleared either when the FIFO becomes empty through reading

all the data (or by reading the holding register), or when a 1 is written to the corresponding bit in the

UARTICR register.”

 

For the first sentence above, if there is simply no more data sent to the UART to receive, why should there be a Receive Timeout interrupt indicating an error?

That is, no further data is expected so why is that identified as a Receive Timeout?

 

Based on the second sentence, is the first sentence supposed to be interpreted something like as follows?

“If the Interrupt Service Routine (ISR) exits without reading all the data in the FIFO, a Receive Timeout interrupt will occur.”

 

I have two UARTs running in a Tiva TM4C1290NCZAD (ARM Cortex M4F) for which the ISRs simply call the Tiva Peripheral Driver Library function UARTIntClear(), read all data available from the FIFO, and then return.

Therefore, since “The receive timeout interrupt is cleared when the FIFO becomes empty through reading all the data”, there should theoretically be no Receive Timeout interrupts.

However, there are Receive Timeout interrupts (for both UARTs).

 

I would like to know why Receive Timeout interrupts occur even when “the FIFO becomes empty through reading all the data” in the ISR.

 

Thank you for your time,

Tim

 

  • 0
    TI__Guru**** 244400 points
    Hello Tim.

    That should not be the case. As you mentioned the Receive TO is only when data is in the FIFO. Can you check the UARTFR register in the code. Note that do not do the same in the Debug Memory or register Window. Also can you check from the last read of the byte when is the RXTO asserted?

    My suspicion is that it is getting asserted while the read is ongoing.

    Regards
    Amit
  • 0
    Guru 27665 points

    Timothy Ball said:
    For the first sentence above, if there is simply no more data sent to the UART to receive, why should there be a Receive Timeout interrupt indicating an error?

    You've read it wrong, see bolded

    Timothy Ball said:

    The receive timeout interrupt is asserted when the receive FIFO is not empty, and no further data

    is received over a 32-bit period when the HSE bit is clear or over a 64-bit period when the HSE bit

    is set.

    The idea is if the uart has not received enough characters to fill the FIFO to the trigger point and no further are arriving then an interrupt will occur so the characters are not lost.

    This is common on FIFOed UARTs and the RTI is usually indistinguishable from a received character interrupt.

    Robert

  • 0 in reply to Amit Ashara
    Expert 1175 points

    Hello Amit:

     Thank you for the swift response.

     The values of the UART Flag Register change between 0X187 and 0X197 using the variable ‘fr’  in the Code Composer Studio graphic below:

    As you indicated, the value in the Registers window may be different than that written to memory at the point that the UART Flag Register is read.

     It appears that the flags RI, TXFE, DCD, DSR, and CTS are always set (0X187) and RXFE is occasionally set as well (0X197) when UART_INT_RT is asserted.

    Also, it appears that the last 2 bytes read before UART_INT_RT is asserted is a carriage return (CR: 0X0A) and line feed (LF: 0X0D) character which is what we expect.

     Thank you,

    Tim

  • 0 in reply to Robert Adsett
    Expert 1175 points
    Hello Robert:

    Thank you for your reply.
    So is the Receive Timeout used to indicate that there is data in the FIFO but not enough to trigger UART_INT_RX based on what the FIFO Level was set to?
    If so, does that mean that the Receive Timeout is not an error but just an indicator that there is FIFO data and, based on the baud rate, another character was expected but not necessarily required by now (e.g. if data is coming in at an inconsistent rate).

    Thanks,
    Tim
  • 0 in reply to Timothy Ball
    TI__Guru**** 244400 points
    Hello Tim

    Now if you read the UARTDR register when RT is asserted what does the Data Read back as?

    Regards
    Amit
  • 0 in reply to Timothy Ball
    Guru 27665 points

    Timothy Ball said:
    So is the Receive Timeout used to indicate that there is data in the FIFO but not enough to trigger UART_INT_RX based on what the FIFO Level was set to?

    Yes and no more received in some period of time.

    Timothy Ball said:
    If so, does that mean that the Receive Timeout is not an error but just an indicator that there is FIFO data and, based on the baud rate, another character was expected but not necessarily required by now (e.g. if data is coming in at an inconsistent rate).

    It's not an error, just an indicator that there are characters waiting in the FIFO.

    Let's you have a FIFO trigger level of 4 and a packet size of 6 (or a burst) then you will receive 4 characters with the normal receive interrupt, then the remaining 2 with an RTI.

    Note, there are two ways of emptying the FIFO

    1. read a fixed number of bytes
    2. read until the FIFO is empty

    The latter reduces the number of interrupts in a high baud rate environment.

    Robert

  • 0 in reply to Amit Ashara
    Expert 1175 points

    Hello Amit:

    As shown in the graphic below, 6 characters were available and read after UART_INT_RT was asserted.

    Evidently, UART_INT_RX was not asserted (status bit 0x00000010 would have been set if so) because there were only 6 bytes, and not 8 or more bytes, residing in the FIFO (default FIFO Level of 4/8 used to trigger on 8 bytes or more of 16).

    Thanks again,

    Tim

  • 0 in reply to Amit Ashara
    Guru 47900 points

    Amit Ashara said:
    Note that do not do the same in the Debug Memory or register Window.

    Might this have been (just) violated?     We're no fans of the (so) restricted/limited CCS (one vendor - really?) so I flag & present here!

  • 0 in reply to Robert Adsett
    Expert 1175 points

    Hello Robert:

    Thank you for the additional information.

    I was originally under the impression that Receiver Timeout was some sort of an error, as I thought SSI_RXTO was, but as you indicate it is only an indicator.

    Your explanation makes perfect sense.

    The Tiva Peripheral Driver Library SSI flags comments for RX timeout and RX overrun do not include the word ‘Error’ but I thought they were both errors:

    #define SSI_RXTO                0x00000002  // RX timeout

    #define SSI_RXOR                0x00000001  // RX overrun

    However, the UART flags comments below do specify if it is for an ‘Error’:

    #define UART_INT_OE             0x400       // Overrun Error Interrupt Mask

    #define UART_INT_BE             0x200       // Break Error Interrupt Mask

    #define UART_INT_PE             0x100       // Parity Error Interrupt Mask

    #define UART_INT_FE             0x080       // Framing Error Interrupt Mask

    #define UART_INT_RT             0x040       // Receive Timeout Interrupt Mask

    Thank you Roger and Amit.

    Appreciatively,

    Tim