• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1754 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570 Interrupt priority

Yang ShunFan
Intellectual 570 points

Dear all,

I am trying to remap the interrupt priority. I build a project and enable 2 interrupt sources, (rtiCompare0Interrupt, etpwm1Interrupt)

The frequency of rtiCompare0Interrupt is 1Hz. The counter is RTICRT.

The frequency of etpwm1Interrupt is 1MHz. The counter is PWMCRT.

When I use default setting for interrupt priority, the test result is normally. I run the program about 7 sec.

However, when I remap the priority, No.2<->No.90,

the test result show only 1 Hz interrupt request in the two counters.

In my opinion, RTICRT should change to 1MHz, and PWMCRT should change to 1Hz.

Could you help solve my confuse? Also I attach my project as follow.

8867.20150225interrupt.rar

  • 0
    TI__Guru 59540 points
    Hi Fan,

    The issue is you have swapped the channels the request lines are mapped to but retained the ISR vector for the prior interrupt type. This is causing the given interrupt to enter the ISR, increment it's counter, but not clear it's associated interrupt flag. This, in turn, is causing the more frequent event's (1MHz ePWM interrupt) interrupt to be suppressed and only fire at the same rate as the slower one (1KHz RTI compare) since it is cleared in the ISR of the slower event.

    To make the remapping correct replace the remapping lines with:

    vimChannelMap(2, 90, &rtiCompare0Interrupt);
    vimChannelMap(90, 2, &etpwm1Interrupt);

    The key is the ISR vectors for the given function need to map to the request line/channel assignment.
  • 0 in reply to Chuck Davenport
    Intellectual 570 points

    Dear Chuck,

    Thanks a lot for your reply.

    I try your way to test it again.

    However, the result is that the counters are not swap each other.

    Could you continue to explain it? Also, could you explain the mean of third arity of vimChannelMap function?

    My project is attached as follow.6138.20150225interrupt.rar

  • 0 in reply to Yang ShunFan
    TI__Guru 59540 points
    Hello Fan,

    The counters will not be swapped since the counters are incremented within the interrupt service routines. I think the point of confusion is the difference between the interrupt request line and the channel to which the interrupt request is mapped.

    The interrupt request line is permanently connected with the interrupts for the associated HW. In other words, the RTI compare 0 interrupt request line is always connected to the RTI module and the compare 0 event. This request line can be mapped into an interrupt channel which feeds into the CPU and is associated with the interrupt vector table. When interrupt request line 2 (RTI compare0) fires, it causes a jump to the vector associated with channel 2 as was the case with your original code without remapping.

    When you remap interrupt request line 2 to channel 90, you must also change the vector that is associated with channel 90 so that it is the corresponding ISR for the RTI compare 0 interrupt. This is because the corresponding code for the RTI compare 0 ISR clears the RTI compare 0 interrupt so the next one can occur. Since RTICRT is incremented in the rtiCompare0Interrupt service routing, remapping the interrupt to channel 90 does not impact the value of the counter(s).

    Remapping the interrupts, only will impact the priority of one interrupt over the other in case they both occur at the same time.

    What is the context of "third arity of vimChannelMap function?" I am not able to see this phrase in any of the prior posts and it doesn't make since to me the way it is written.
  • 0 in reply to Chuck Davenport
    Intellectual 570 points

    Chuck,

    Thanks a lot. The answer totally solve my confuse.

    Otherwise, for the "third arity of vimChannelMap function", my question is:

    For vimChannelMap function:

    Could your explain more detail about the third parameter? (handler)

    For example, what is the difference between the following instruction?

    vimChannelMap(2, 90, &rtiCompare0Interrupt);

    vimChannelMap(2, 90,  &etpwm1Interrupt);

    I have some confuse on it. 

  • 0 in reply to Yang ShunFan
    TI__Guru 59540 points
    Hi Fan,

    The parameter "handler" is a function pointer to the interrupt service routing and is mapped to the interrupt channel during the call to vimChannelMap. i.e., when the interrupt fires, the request is asserted to the CPU on the channel assigned and the program execution jumps to the address of the interrupt service routine and, on completion of the interrupt service routine, returns back to the normal flow where it was interrupted. This handler is also called the interrupt vector for the associated interrupt request.