• State TI Thinks Resolved
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 25 views
  • Users 0 members are here
Support feedback
Options
Options
Related

F29H850TU: How to identify when the same interrupt is triggered again using the OVERFLOW_FLAG in PIPE module?

Sumukh Ananth
Prodigy 110 points
Part Number: F29H850TU

Tool/software:

In F29x, the PIPE module is quite different from PIE modules in F28x targets.

I am aware that the discussion in this question: F29H850TU: How to nest the same interrupt (e.g., INT_TIMER0) in the C29 core architecture? - C2000 microcontrollers forum - C2000Tm︎ microcontrollers - TI E2E support forums says that cyclic nesting the same interrupt is not recommended.
I am not trying to nest the same interrupt within itself.
I just want to detect when another instance of the same interrupt has been triggered while the current interrupt's ISR is being executed.

Say, INT_TIMER0 interrupt has been configured to trigger every 1sec.
Now, suppose the ISR corresponding to it is taking more than 1 sec to execute, and before the ISR even finishes, INT_TIMER0 is triggered again after 1 sec.

Now, if that happens, how do I detect that another instance of the timer interrupt has occurred while the current interrupt ISR is being serviced? 

The OVERFLOW_FLAG bit of this interrupt within the INT_CTL_L_y register appears to state in the TRM that it gets set to 1 whenever another instance of the same interrupt has been triggered, but I am unable to work with it as it gets set in the first ISR call itself and I cannot understand why.
The TRM of this processor does not explain much about the use of this flag bit and it also appears to have a dependency on the FLAG bit of the same register, which is not very clear, as I see in CCS that OVERFLOW_FLAG is getting set to 1 even though FLAG bit remains 0. 

So, to summarize, my question is:
Can the OVERFLOW_FLAG bit be used to detect if the same timer interrupt has been triggered again while the current timer interrupt ISR is being executed? 
If not, is there any other way to detect this, some CPU INT stack bit, or some way to use the INTSP register to detect this ISR task overrun?



  • 0
    TI__Genius 15905 points

    Sumukh,

    How OVERFLOW_FLAG Works:

    1. When an interrupt (like INT_TIMER0) occurs, the hardware sets the FLAG bit in INT_CTL_L_y.
    2. If another instance of the same interrupt occurs while the FLAG bit is still set, the OVERFLOW_FLAG bit gets set.
    3. The FLAG bit is typically cleared automatically when the CPU acknowledges the interrupt.
    4. The OVERFLOW_FLAG, however, must be cleared by software.

    Why Your OVERFLOW_FLAG Gets Set Immediately:

    If you're seeing the OVERFLOW_FLAG set during the first ISR call, it likely means one of the following:

    1. The interrupt is occurring very frequently (faster than your ISR can acknowledge it).
    2. The FLAG bit isn't being cleared properly between interrupts.
    3. There might be an initialization issue where the OVERFLOW_FLAG wasn't cleared before enabling interrupts.

    How to Debug OVERFLOW_FLAG:

    As overflow bit could get set for any interrupt state beyond Pended, the ISR needs to check and address underlying overflow condition before it clears this. I would recommend a global flag/counter (ie. timerOverrunCount) that is set at the beginning of ISR to track how many times an ISR is executed and check if an overrun condition has occurred. You can also look at the CPU TIMER interrupt-based SDK example that actually showcases these concepts.

    Best Regards,

    Aishwarya