• State
  • Replies 11 replies
  • Subscribers 34 subscribers
  • Views 247 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM2434: Concerns regarding the i2310 issue on AM243x

liang luo
Prodigy 240 points

Part Number: AM2434

Hi TI Experts, 

We have a product that, during low-temperature UART communication stress testing, was found to trigger the i2310 fault multiple times. This fault cannot be cleared effectively immediately, causing repeated FIFO timeout interrupt events and resulting in an interrupt storm. If an external watchdog, MAX706, is used to control chip reset, this interrupt storm can prevent the watchdog from being fed in time, thereby causing a system reset.

  1. The UART configuration is shown in the figure below, RX trigger level = 1 byte, and the interrupt mode uses "user managed interrupt" mode.
    image.png

  2. The UART interrupt handling is as follows:

  3. We recorded the number of timeouts and read it after about ten minutes of testing. The timeout count reached the millions, while other prototype units running the same code either do not exhibit this issue or have only one or two occurrences.
    image.png

Is the i2310 workaround really a verified and reliable solution? Are there any other recommended measures?

  • 0
    TI__Expert 4000 points

    Hello Iiang Iuo,

    The behavior you are observing is related to Silicon Errata i2310 USART: Erroneous clear/trigger of timeout interrupt. This errata affects all both AM243x silicon revisions (1.0 and 2.0) and has no hardware fix.

    The specific failure mode in your case is the erroneous set of the timeout interrupt with an empty FIFO, which, under low-temperature stress conditions, is triggering at an extremely high rate. This is consistent with the errata being a probabilistic, temperature-sensitive analog behavior within the USART block, which also explains why other units running identical firmware show zero or minimal occurrences. The SW workaround is the official TI-recommended mitigation and it is verified to clear a single spurious timeout interrupt event. 

    Best Regards,

    Borislav Lazarkov

  • 0 in reply to Borislav Lazarkov
    Prodigy 240 points

    Hi Borislav,

    What is questionable is that, as in the interrupt code above, we used WA2310 to fix it, but it is clear that the interrupt cannot be effectively cleared; instead, it keeps being entered repeatedly, causing even the user thread and the FreeRTOS SysTick interrupt to fail to execute (because the SysTick interrupt priority is lower than that of the UART interrupt). That is why we suspect the effectiveness of WA2310():

    If it could solve the problem, if that TIMEOUT interrupt were effectively cleared, then an interrupt storm should not occur..

    liang luo said:
    The UART interrupt handling is as follows
  • 0 in reply to liang luo
    Prodigy 240 points

    Hi Borislav,

    We performed the simple test described below: after executing the WA2310() workaround patch, we rechecked the IIR interrupt register and found that IT_TYPE still indicated a TIMEOUT interrupt, as shown in the figure below. The readings from the uart_timeout2_cnt and uart_timeout_cnt counters are consistent. Does this mean the timeout interrupt was not cleared successfully?

  • 0 in reply to liang luo
    TI__Mastermind 30817 points

      

    Customer feedback it is more easy to reproduce at low temperature -10C. Do you know is it sensitive to temperature? If the condition remains, will it retrigger the issue repeatedly and frequently?

      

    Customer referred MCU SDK workaround code to clear error FIFO interrupt, but it keeps re-enter, and read interrupt status register just after clearing, the interrupt status is not cleared.  is it due to new error interrupt triggered again, or the workaround code doesn't clear status at all?

  • 0 in reply to Tony Tang
    TI__Guru 59485 points

    Hey Tony,

    Can you please check with the customer if they have incorporated this fix in the SDK which they are using?

    Fix can be seen here in the form of a commit: https://github.com/TexasInstruments/mcupsdk-core/commit/b7a675a664aeb1d552dc21147adb8bbe130c9a58

    Looking forward to your response.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 240 points

    Hi Vaibhav,
    Our implementation follows the strategy of SDK12; the detailed code is attached below.

    liang luo said:
    The UART interrupt handling is as follows:

    I guess you brought up this question because i2310wa in SDK11 doesn't actually work; we've noticed this.

  • 0 in reply to liang luo
    TI__Guru 55648 points
    Hello,
    Does this issue happen at room temperature as well?
    Also, can you confirm if the control is exactly entering the workaround (i2310wa WA) function inside the ISR when the Timeout occurs?
    Regards,
    Anil
  • 0 in reply to Swargam Anil
    Prodigy 240 points

    It also occurs at room temperature, but the probability is much lower.
    You can look at our logs above—we record the number of entries, and call i2310wa() at the same time.

  • 0 in reply to liang luo
    TI__Guru 59485 points

    Hi,

    The profiling you did for the following is pretty good and helpful: 

    liang luo said:
    The readings from the uart_timeout2_cnt and uart_timeout_cnt counters are consistent. Does this mean the timeout interrupt was not cleared successfully?

    I am debugging this, please expect responses in sometime.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Kumar
    Prodigy 240 points

    Hi Vaibhav,

    Maybe due to this error in source/drivers/uart/v0/uart_v0_lld.c

  • 0 in reply to liang luo
    TI__Guru 59485 points

    Hi,

     rightly figured this out. His change which directly writes to the 6th bit works out just fine.

    The current device range(AM62x, AM62Px, AM62Ax and so on) already has this fix incorporated: github.com/.../uart_v0.c

    A bug has been raised to fix this.

    Regards,

    Vaibhav