• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 647 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.

TDA4VM: TDA4VM Errata i2310 USART: Erroneous clear/trigger of timeout interrupt

Nazim Haque
Prodigy 110 points

Part Number: TDA4VM

Dear TI Support,

With reference to below errata could you please support us with more information.

-------------Errata text start------------

i2310 USART: Erroneous clear/trigger of timeout interrupt
Details: The USART may erroneously clear or trigger the timeout interrupt when RHR/MSR/LSR
registers are read.
Workaround(s):
For CPU use-case.
If the timeout interrupt is erroneously cleared:
-This is OK since the pending data inside the FIFO will retrigger the timeout interrupt
If timeout interrupt is erroneously set, and the FIFO is empty, use the following SW
workaround to clear the interrupt:
- Set a high value of timeout counter in TIMEOUTH and TIMEOUTL registers
- Set EFR2 bit 6 to 1 to change timeout mode to periodic
- Read the IIR register to clear the interrupt
- Set EFR2 bit 6 back to 0 to change timeout mode back to the original mode

-------------Errata text end------------

Question 1 : If timeout interrupt is erroneously set, is reading IIR register not sufficient to clear the interrupt?

Question 2: What is the reason behind setting EFR2[6]? Is this only to trigger a timeout interrupt by force on empty Rx FIFO?

Thank you

BR,

Nazim

  • 0
    TI__Genius 17176 points

    Only the Workaround provided in the Errata documented is supported and validated. I do not know the answer to your questions. Do you have any issues implementing the Workaround?

  • 0 in reply to B.C.
    Prodigy 110 points

    Hello,

    I have no issue implementing the workaround. Could you please at-least share the use-case to reproduce this issue. This way i can ensure the provided workaround resolves the problem.

    Thanks

  • 0 in reply to Nazim Haque
    TI__Genius 17176 points

    There is no way to force the issue to occur or to make it occur more often, since it is related to an unsynchronized internal signal.

  • 0 in reply to B.C.
    Prodigy 110 points

    Is this issue detected in Silicon Revision 1.1 as well.

  • 0 in reply to Nazim Haque
    TI__Genius 17176 points

    Yes, please reference the "SILICON REVISIONS AFFECTED" columns of the "Advisories by Modules" table in the Errata.

  • 0 in reply to B.C.
    Prodigy 110 points

    For DMA use-case.
    If timeout interrupt is erroneously cleared:
    -This is OK since the next periodic event will retrigger the timeout interrupt
    -User must ensure that RX timeout behavior is in periodic mode by setting EFR2 bit6 to 1
    If timeout interrupt is erroneously set:
    -This will cause DMA to be torn down by the SW driver
    -OK since next incoming data will cause SW to setup DMA again

    -------

    For DMA use-case could you please explain in more detail-

    1.  Setting TIMEOUTL and TIMEOUTH to a high value not needed?

    2. What is meant by "This will cause DMA to be torn down by the SW driver"?

  • 0 in reply to Nazim Haque
    TI__Prodigy 370 points

    Nazim,

    1>

    UART of two types of timeouts  See 12.1.6.4.8.1.3.7 Time-Out and Break Conditions

    • In default operation on the [6] TIMEOUT_BEHAVE is set to 0. 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 RX or when the
    register is read.
    • Optionally, for choose to enable the timeout counter even if no character has been received by setting [6]
    TIMEOUT_BEHAVE bit. This will generate periodic interrupts if the RX line remains idle. In this mode the
    counter will auto-reset when a timeout has been reached. Reading the will clear the interrupt, but not the
    counter.

    In default mode, timeout is cleared by reading FIFO data and periodic mode, reading IIR will clear the interrupt

    In DMA mode SW is expected to use periodic mode (FIFO Is being drained by DMA), thus reading IIR is sufficient to clear erroneous timeout and there is no need to play with TIMEOUTL/H Registers. In CPU mode, SW most likely will be in default timeout mode and since FIFO would have no data in errata case, clearing timeout by reading FIFO isn't possible. So SW is expected to switch to periodic mode and read IIR to clear interrupt.

    2>
    "This will cause DMA to be torn down by the SW driver" ->  Linux/RTOS UART DMA driver will teardown (stop) DMA channel on UART timeout interrupt (end of current transfer) and push whatever data was received by DMA up until then to upper layers