• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1196 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.

AM3352: UART Receive Timeout but FIFO empty

PAUL HETHERINGTON
Intellectual 470 points
Part Number: AM3352
Other Parts Discussed in Thread: AMIC110

Very intermittently we're getting a UART Receive time-out but the receive FIFO is empty.

My understanding from the users manual is that this is not possible. There must be data in the FIFO for this timeout to occur.  Is this a known problem? Solution or workaround?

We're using the UART described in Chapter 19 of the AM335x and AMIC110 Sitara Processors Technical Reference Manual.

TI AM335x TRM Rev P spru73p.pdf

19.3.8.1.3.7.1 Time-Out Counter
An RX idle condition is detected when the receiver line (uarti_rx) is high for a time that equals 4x the
programmed word length + 12 bits. uarti_rx is sampled midway through each bit.
For sleep mode, the counter is reset when there is activity on uarti_rx.
For the time-out interrupt, the counter counts only when there is data in the RX FIFO, and the count is
reset when there is activity on uarti_rx or when the UARTi.UART_RHR register is read.

  • 0
    TI__Guru**** 170625 points
    Hi Paul,

    Note that we have some UART advisories in the silicon errata:

    www.ti.com/.../sprz360i.pdf

    Please check this doc, you might be hitting the errata.

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 470 points

    Hi Pavel,

    Re Advisory 1.0.35: UART: Transactions to MDR1 Register May Cause Undesired Effect on UART Operation. The description doesn't seem related to the Receive Timeout and FIFO level.  However, I do have a question about it.

    It sounds like the Advisory is saying that accessing MDR may interfere with the UARTs operation. In other words, if your code is not accessing the MDR, than UART operation would not be disturbed. Is that correct? Or, is it saying that incorrectly initializing MDR during at start-up may result in malfunction  at a later point in time, during operations? The problem we're seeing is preceded by large amount of successful  UART communication.

    Re the UART Receive Timeout and the FIFO being empty. One theory is that there is a small time window before the timeout is set during which reading the last character from the FIFO will not prevent the timeout from being raised. Is that possible?

    Reference code example of UART interrupt based operation?

    Thanks in advance,

    Paul Hetherington

  • 0 in reply to PAUL HETHERINGTON
    TI__Guru**** 170625 points

    Paul,

    PAUL HETHERINGTON said:
    In other words, if your code is not accessing the MDR, than UART operation would not be disturbed. Is that correct?

    Yes, this is what I also understand.

    PAUL HETHERINGTON said:
    Re the UART Receive Timeout and the FIFO being empty. One theory is that there is a small time window before the timeout is set during which reading the last character from the FIFO will not prevent the timeout from being raised. Is that possible?

    Yes, seems you have some timing/sync issue.Check if the below e2e thread will be in help:

    PAUL HETHERINGTON said:
    Reference code example of UART interrupt based operation?

    Do you use AM335x TI PSDK Linux v5.02 (kernel v4.14.79)?

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 470 points
    Hi Pavel,

    Thanks for the feedback. My understanding is that this issue is not related to known errata. I am still at a loss as to how there is a UART receive timeout interrupt raised when the receive FIFO is empty.

    Thanks
    Paul
  • 0 in reply to PAUL HETHERINGTON
    TI__Guru**** 170625 points
    Paul,

    This unexpected/spurious interrupt might be caused by misconfiguration and/or not properly protected resources. Check below e2e thread for example:

    e2e.ti.com/.../2569775

    Do you use AM335x TI PSDK Linux v5.02 (kernel v4.14.79)?

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 470 points

    Hi Pavel,

    We're using Mentors Nucleus OS.

    Our interrupt code isn't disabling interrupts or using locks. Is one of these necessary for the UART interrupt on this processor?

    Thanks again,

    Paul

  • 0 in reply to PAUL HETHERINGTON
    TI__Guru**** 170625 points
    Paul,

    This is SW specific, I can not advice regarding Mentors Nucleus OS. You can check your SW with Mentor support team.

    From HW side, I suspect that you receive timeout interrupt when there is data in the FIFO, but then when you check the FIFO, that data has been transferred or the FIFO has been reset/cleared.

    If you receive timeout irq, you should read UART_RHR regster, thus clear this interrupt (Interrupt Reset Method), or you can get this interrupt again, when there is no data in FIFO.

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    TI__Guru**** 170625 points
    If you have no more questions related to the subject of the e2e thread, please close/verify/resolve this thread.

    Regards,
    Pavel