Interrupt missing because of an exception in IVOR4_Handler

[sagardhavali]

Application description:

We working on a motor control application. In this application motor control algorithms and parameters are run and calculated in an interrupt generated by CTU at every 100us as our PWM is configured to be 10KHz.

Problem definition:

We've seen this interrupt to miss the timing of every 100us; in other words, it is delayed.

 The below picture is the waveform generated using a GPIO set to high as program control enters the ISR and the same GPIO set to low as program control exists the ISR. The cursor B is where actual ISR should have been serviced but is instead serviced at the cursor A position accounting to delay of 50us.

Problem Area:

I connected debugger and the stack to see where is this happening and I found an exception in IVOR4_Handler. I think this related to the problem explained above.

Question:

1. How do I know what is causing this exception?

2. I read through IVOR4 exception briefly in e200z4RM.pdf as suggested in another post and I found the following statement.

"An external input interrupt may be delayed by other higher priority exceptions or if MSR[EE] is cleared
when the exception occurs."

In my configuration, interrupt ADC_I_CTU_0 (#713), interrupt ERR_I_CTU_0 (#714) and interrupt MRS_I_CTU_0 (#700) are all configured with highest priority (Priority 11 and there exist no interrupt with higher priority).

Question is, are these all related? Does interrupt related to MRS_I_CTU_0 needs to have different priority given the statement above?

Any suggestion/solution is highly appreciated. Many thanks in advance.

Thanks,

Sagar

[davidtosenovjan]

Hi, I agree with the asnwer above (if you are using SW vectror mode, apparently yes as in HW vectore mode IVOR4 should be completely inactive).

Just to add some info - if all 3 interrupt sources are of equal priority and all 3 request assert at the same time, the INTC will first select the lowest numbered interrupt source. However delay is mostly caused by in case nesting feature is disabled (ISR is pending until end of another ISR).

I would recommend to assign unique priorities if you can and enable nesting feature to guarantee fastest ISR response of critical ISR.

[jamesmurray · Accepted solution]

If you want that interrupt handler to run as close to time as possible, you do need to give it a higher interrupt priority than other interrupts. You also need to make sure nothing else is masking interrupts and that you don't have any accidental busy-waits or similar in other interrupt code that will prevent this ISR from being serviced.

IVOR4 is how the PowerPC core handles interrupts from a module outside the core, so most "normal" interrupts go through it. (The other IVORs are actual faults.) So that part of your debug information looks normal  (I think!)

James