• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 359 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.

TMS320F280049C: Inquiry Regarding Interrupt Handling in C28x

Conor
Guru 14780 points

Part Number: TMS320F280049C

Tool/software:

Hi,

I am currently developing an application using a TI C2000 microcontroller and have a question regarding its interrupt handling behavior.

As I understand, the C2000 architecture does not support nested interrupts by default. In my case, I have an interrupt that occurs every 50 µs. However, the interrupt service routine (ISR) sometimes takes longer than 50 µs to complete (e.g., 70 µs).

In this scenario, I would like to confirm the expected behavior:

  1. When the next interrupt request occurs at 50 µs while the previous ISR is still running, does the new interrupt get immediately processed, or does it remain pending until the current ISR finishes?
  2. If the interrupt remains pending, does it get serviced immediately after the current ISR finishes (i.e., at 70 µs), or does it wait until the next scheduled interrupt cycle (i.e., at 100 µs)?
  3. Is there any risk of ISR re-entry or unintended execution overlap under the default settings?
  4. If necessary, what is the recommended approach to prevent ISR overload or processing delays in such cases?

I would appreciate any clarification on these points and any guidance on best practices for handling high-frequency interrupts efficiently in C2000.

Thanks,

Conor

  • 0
    TI__Mastermind 25440 points

    Hi Conor,

    If another (of the same) interrupt comes in during an ISR's execution, it would be latched by the PIE module, meaning it will execute immediately after the current ISR has finished executing. This is due to the portion of the interrupt handling sequence highlighted below:

    In your case since your interrupt is occurring periodically, ISR execution will be delayed more and more with each interrupt and would eventually cause lost ISRs. My suggestion here would be to shorten your ISR as much as possible to try to get it below 50us. Are you doing any function calls inside (that aren't inline functions)? Are there any blocking operations taking place? Is there any code that can be done outside of the ISR instead?

    Alternatively, it may be a good idea to slow down your interrupt frequency to have a period greater than 70us if that would work for your application.

    Best Regards,

    Delaney