• State
  • Replies 6 replies
  • Subscribers 84 subscribers
  • Views 225 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

Original question:

TMS320F28377D: Timer priority between timer-0 and timer 1

TMS320F28386S: Interrupt priority of timers

Rainer Engelhardt
Prodigy 10 points
Part Number: TMS320F28386S
Other Parts Discussed in Thread: TMS320F28377D, C2000WARE

Tool/software:

in a reply to a question about priorities of timers (TMS320F28377D: Timer priority between timer-0 and timer 1) the support wrote:

"It looks like the behavior you are seeing isn't due to the fact that Timer 1 has a higher priority than Timer 0, but rather that the Timer 1 interrupt is coming in first, and since there is no nesting enabled, it will run to completion even if an interrupt for Timer 0 comes in during the execution. By default, ISRs will complete execution before servicing the next interrupt that is both enabled and flagged. If you want Timer 0 to always be immediately serviced no matter what, you will have to enable nesting inside the Timer 1 interrupt. "

Does this apply to all interrupts? Interrupt PIO group 1 has a priority of 5. A NMI or RTOSINT would have a lower interrupt and in my understanding should be able to interrupt a ISR with a lower priority.

Best regards,

Ray

  • 0
    Prodigy 10 points

    Sorry - I meant NMI and RTOSINT have a lower priority number and therfore a higher priority and should be able to interrupt a Timer0 or Timer1 ISR, which have lower priorities.

  • 0 in reply to Rainer Engelhardt
    TI__Mastermind 22050 points

    Hi Ray,

    This expert is currently out of office. Please expect a delay in response until their return next week. 

    Thanks & Regards,

    Allison

  • 0 in reply to Allison Nguyen
    TI__Genius 15875 points

    Hi Ray,

    I apologize for my delayed response.

    To be more specific, all maskable interrupts on C28x by nature will run to completion once they are started unless nesting is implemented. Maskable interrupts include INT1-14, DLOGINT, and RTOSINT. This is due to the hardware connection of all these interrupts to the CPU. When one of these ISRs is branched to, the IER of the specific interrupt is disabled, DINT is called (disables INTM bit), and the ACK for the group switch is opened.

    NMI interrupts on the other hand are directly connected to the CPU and will always be branched to. They are no effected by the INTM bit or IERS/ACKs. See the description below.

    The group numberings overall are showing the priority scheme for if two interrupts were to come in at the same time. So, to answer your question, that statement applies to RTOSINT but not to NMIs. I would suggest taking a look at the CPU Interrupts and Reset section of the C28x CPU Reference Guide (linked here) for more explanation on this.

    Please upvote this response if it was helpful. Slight smile

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 10 points

    Hello,

    OK - that helped me to some point.
    The next question is- does this then apply also to RTOS interrupt (I fear yes)?

    We have a software which hangs-up from time to time without an obvious reason. As even the watchdog (which is used to call an ISR) does not work and the CLA seem to stop working, my best guess is, that an ISR does not return and hangs in an infinite loop. This would then prevent other maskable ISRs - like the watchdog ISR or the ISR that triggers the CLA - to be executed. So I thought that perhaps the ERAD could be used to check e.g. if the main loop is re-executed  within a certain time and if that fails to trigger an RTOS interrupt. But as this one is also maskable - although it has a high priority - this one then is also blocked - I guess?

    Is there a possibility to cause an NMI whitin the ERAD, because this ine is non-maskable so it should - in my opinion - interrupt an ISR of a maskable interrupt.

    Best regards,

    Ray

  • 0 in reply to Rainer Engelhardt
    TI__Genius 15875 points

    Hi Rainer,

    Yes, RTOSINT should run to completion after it starts executing if no nesting is enabled. 

    Are you able to attach a debugger to your application? This would allow you to add counters to the different ISRs and also pause the code to see where it is potentially getting stuck.

    If not, could you add GPIO toggles to different portions of your code (perhaps at the beginning and end of each ISR and one in the background loop) to try and understand what is happening?

    I will loop in the ERAD expert to make any suggestions as well.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    TI__Mastermind 19284 points

    Hi Ray,

    If you're looking to use ERAD to help track the execution order of your interrupts, you can leverage the ERAD Interrupt Order example (erad_ex6_interrupt_order) provided in C2000Ware.3

    This example uses a COUNTER to monitor the sequence of ISRs executed. An interrupt is generated if the ISRs executed are not in the expected order.

    The full list of ERAD examples can be found here: 

    https://dev.ti.com/tirex/explore/node?node=A__AFDafQ8BojiF4hzpDDIgEg__C2000WARE__1kRFgrO__LATEST&placeholder=true 

    Regards,

    Ozino