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

LAUNCHXL2-570LC43: Preemption of same priority interrupt using RTI module | TMS570LC4357

Naveen R
Prodigy 50 points

Part Number: LAUNCHXL2-570LC43
Other Parts Discussed in Thread: TMS570LC4357

Hi TI Team, 

We are using RTI Module in TMS570LC4357 Launchpad to schedule a task for every 10ms with same priority IRQ. We could able to see the interrupt which is triggered at every 10ms. where I am using VIM channel 2 which is mapped to rticomp0interrupt. But when the task is beyond 10ms the next cycles are in pending state until the current task is completed. 

As per my requirement, I need to preempt the the current task if it goes beyond 10ms and Log the fault. If it's within the 10ms then I need to execute those tasks and wait for the next interrupt request with same priority. 

Please guide me through this issue.

Thanks and Regards, 
Naveen R.

  • 0
    TI__Guru* 75366 points

    Hi Naveen,

    The behavior you're seeing is the default interrupt handling mechanism of the ARM Cortex-R4F core in the TMS570LC4357. Here's why this is happening:

    1. No Hardware Nesting for Same Priority: By default, when an interrupt is being serviced, the processor disables further interrupts of the same or lower priority. This is why your subsequent 10ms
    interrupts are being held pending.
    2. VIM Configuration: The Vectored Interrupt Manager (VIM) in the TMS570 also has a priority scheme. When an interrupt occurs, the VIM masks out interrupts of the same or lower priority until the current
    one completes.
    3. No Self-Preemption: Without special handling, an interrupt cannot preempt itself. When RTI Compare 0 interrupt is being processed, subsequent RTI Compare 0 interrupts will be pending until the current
    handler completes.

    This is why your long-running task blocks subsequent 10ms interrupts - there is no built-in mechanism for same-priority interrupt nesting or self-preemption.

    For more details refer below App notes once:

    3817.Nested Interrupts on Hercules spna219.pdf

    --
    Thanks & regards,
    Jagadish.