• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 333 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM2634-Q1: RTI interrupt will not issue to VIM if the previous RTI interrupt flag is not cleared?

Will Gao
Intellectual 2335 points
Part Number: AM2634-Q1
Other Parts Discussed in Thread: SYSCONFIG

Hi BU, 

The background is customer found that their timer-based periodical tasks not run anymore after their board working continuously for 9 days. 

From my understanding, there are 2 stages for handling the interrupt inside the chip hardware: RTI interrupt generation logic + VIM interrupt prioritizing and processing. After RTI INT condition is met, the VIM IRQ STS should be set and waiting to be active. 

I wrote a program to understand the hardware behavior. And it seems that from hardware behavior, the corresponding VIM IRQ STS will not set if the previous RTI INT Flag is not cleared. To better manifest this, please see following fig: 

And the test codes is attached: timer_int_not_handled.zip

I have following thoughts: 

1). the root reason for this issue is that when the previous RTI INT flag is not cleared, the latter RTI INT will not issue to VIM to set the VIM INT STS, right?  

2). change the attribute of type from Pulse to Level to solve this problem; 

3). enable the periodical flag clearing feature in RTI to solve this problem. 

Please check this issue and give your suggestions, thanks. 

BR, 

Will 

  • 0
    TI__Mastermind 25945 points

    Hi Will,

    I tried the SW you provided and I could not find the exact issue and I am still working on it but I went on to try the example and this works as per the expectations - https://software-dl.ti.com/mcu-plus-sdk/esd/AM263X/latest/exports/docs/api_guide_am263x/EXAMPLES_KERNEL_DPL_INTERRUPT_PRIORITIZATION.html

    all-trace-functionality.diff
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    .../am263x-cc/r5fss0-0_freertos/example.syscfg | 6 +++---
    .../dpl/interrupt_prioritization/interrupt_prioritization.c | 12 ++++++++++++
    2 files changed, 15 insertions(+), 3 deletions(-)
    diff --git a/examples/kernel/dpl/interrupt_prioritization/am263x-cc/r5fss0-0_freertos/example.syscfg b/examples/kernel/dpl/interrupt_prioritization/am263x-cc/r5fss0-0_freertos/example.syscfg
    index 0946fe00bb..935fe6fc24 100644
    --- a/examples/kernel/dpl/interrupt_prioritization/am263x-cc/r5fss0-0_freertos/example.syscfg
    +++ b/examples/kernel/dpl/interrupt_prioritization/am263x-cc/r5fss0-0_freertos/example.syscfg
    @@ -2,7 +2,7 @@
    * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
    * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
    * @cliArgs --device "AM263x_beta" --package "ZCZ" --part "AM263x" --context "r5fss0-0" --product "MCU_PLUS_SDK@07.03.01"
    - * @versions {"tool":"1.10.0+2163"}
    + * @versions {"tool":"1.14.0+2667"}
    */
    /**
    @@ -49,17 +49,17 @@ mpu_armv74.size = 21;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Try playing around by changing the priority of the interrupts of the different timers via syscfg and understand the working of interrupts and VIM.

    Hope it helps.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    TI__Intellectual 2335 points

    Hi Aakash, 

    The interrupt priority of timer used for ClockP SW component is fixed inside the ClockP driver and can't be configured by SysConfig. 

    The main problem now is why Timer's interrupt can't issue to VIM after the last interrupt flag is not cleared. The project I provided is to illustrate this situation. And the fig I submitted is to demonstrate the timing sequence for this situation. 

    Please help confirm with design team on this RTI hardware behavior. I think for issuing interrupt into VIM, the raw RTI interrupt signal should have a rising edge, and this is why if the flag is not cleared, the following interrupt can't issue to VIM. 

    It is common in application that the RTI interrupt can not be timly cleared due to complex interrupt tasks, e.g. control loop. So from my view, it will be better if the RTI driver/ClockP SW can use the hardware feature- periodically clear the interrupt flag as following: 

    Regards, 

    Will 

  • 0
    TI__Intellectual 1135 points

    I dont have anything extra to add here. You have rightly understood the working.

    VIM supports a Level or pulse interrupt (and one must configure VIM accordingly)

    1. If Level, then first the source has to be cleared and then VIM has to be cleared. This way VIM will not get a false extra interrupt

    2. If Pulse, then you can clear in any order. But the IP has to strictly generate a pulse interrupt.  It it should  generate another edge for VIM to register it as a new interrupt.

    In this example the RTI is generating a level interrupt.  You can use the autoclear feature of RTI and make it into a pulse. Or configure VIM to treat it as a level interrupt. Both works based on how you want the system to setup.

    Regards

    Prithvi