• State
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 113 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM6442: AM6442:Abnormal Timing Interrupt Entry Issue for AM6442

Yang Liu
Prodigy 20 points
Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Dear TI Team,
          I encountered issues while testing the overhead from triggering a timer interrupt to entering it, and I would like to seek your advice.
First, in an empty project, I configured a timer via SysConfig with the following parameters: clock frequency of 25 MHz, interrupt priority of 0, and a 1 ms period. When entering the interrupt callback function, I used TimerP_getCount to read the count value, and calculated the interrupt entry overhead based on this count. During the test, the following phenomena occurred:
   1.In a53ss0-0_nortos, r5fss0-0_freertos, and a53ss0-0_freertos, the interrupt entry overhead was significantly longer for the first few times, reaching a maximum of over 700 microsecond .
2.No anomalies were found in r5fss0-0_nortos the overhead was around 0.48 microsecond , but with a fluctuation of 0.15 microsecond  (maximum: 0.56 microsecond ; minimum: 0.4 microsecond ). Similar fluctuations were observed on other cores, roughly around 0.3 microsecond . When FreeRTOS is used, the fluctuation becomes more severe (up to 2 microsecond ) when two tasks are switching.
      3.A fast SRAM region was defined for the A-core, and a fast TCMB0 region was defined for the R-core. However, the interrupt entry overhead in the fast regions was not lower than that in the slow regions.
 Questions:
Q1: Why is the interrupt entry latency so long, and how should I resolve this issue?
Q2: Why do these fluctuations occur, and are they normal?
Q3: Why are the fast regions not faster ?

Thank you!

  • 0
    TI__Mastermind 48856 points

    Hello Yang Liu,

    I am working on your queries and you may get reply in one or two days .

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    TI__Mastermind 48856 points

    Hello Yang Liu,

    To accurately measure the interrupt entry overhead, we need to carefully define where the timing starts and ends.

    Simply capturing the timer value inside the application callback does not reflect the true interrupt entry overhead.

    Recommended Measurement Approach :
    1. Start the timer in the master ISR, i.e., at the earliest point where the interrupt controller invokes your registered ISR (before calling the application callback).
    2. Read the timer again at the entry of the application callback.
    • The difference between these two timestamps gives the actual interrupt entry overhead .


    Important Measurement Considerations:
    • Perform all measurements in a Release build, not Debug.
    • Debug builds introduce additional compiler instrumentation and optimization differences that affect timing.
    • Use the GTC (Global Time Counter) instead of TimerP_getTime().
    • GTC is a 64-bit free-running timer with much higher resolution and consistency across cores.

    GTC Timer : 

    Master ISR : 

    Regards,

    Anil.

  • 0 in reply to Swargam Anil
    Prodigy 20 points

    Hello Anil,

    1.To add, the method I mentioned earlier for calculating overhead is as follows: first obtain the reload value via TimerP_getReloadCount at the very beginning, then get the current count value using TimerP_getCount() when entering the interrupt, and calculate the overhead time based on the current count value and the reload value.

    2.For GTC_getCount64(), what is the time corresponding to each count value?

    3.What I want to test is the timer interrupt. I don’t understand the purpose of the "Master ISR" you mentioned—could you clarify its function?  ” Start the timer in the master ISR, i.e., at the earliest point where the interrupt controller invokes your registered ISR (before calling the application callback). “Could you please specify the exact operation steps? And could you provide an example routine?

    4.I used GTC_getCount64(). Since I didn't understand the "Master ISR" you mentioned, I tested the time interval between two consecutive interrupt entries. I found that the fluctuations disappeared, but the first few times still showed anomalies.

  • 0 in reply to Yang Liu
    TI__Mastermind 48856 points

    Hello Yang Liu,

    The GTC  runs at 225 MHz.
    Based on the above Results, during the first three occurrences, the timer interrupt is triggered at irregular intervals, but from the fourth time onward, the timer interrupt triggers exactly at the configured 1 ms interval.

    This behavior is mainly due to the FreeRTOS task creation and scheduler initialization sequence.
    During the RTOS initialization phase (for example, while creating tasks or starting the scheduler), global interrupts remain disabled.
    As a result, timer interrupt generated delayed .Once the scheduler completes initialization and re-enables global interrupts, all pending interrupts are serviced immediately, causing the first few interrupts to occur at unexpected times.


    To confirm my analysis , please try method below ,
    1. start the timer only after the scheduler has started (vTaskStartScheduler()).

    And please share the Test Results .

    Regards,

    Anil.