AM2634: Interrupt nesting

Hi 

The interrupts are nested by default. No change is required to be done.

Also check if the interrupts need to be pulse triggered or level triggered depending on your configuration.

You can use 2 INTXBARs so that you can configure two unique ISRs that can be nested easily.

Are you trying this in Free Rtos or No Rtos project?

The interrupt nesting works like this:

1. When we get an interrupt, the interrupt is first handled in the Hwip_IRQ_handler, Hwip_IRQ_handler_c. This is where the context saving and register status saving takes place.

2. When step 1 is happening interrupt nesting is disabled to avoid stack corruption while context saving.

3. After the step 1 is done, we jump into the Application ISR (the ISR defined by you for that particular interrupt). Before this jump happens we enable Interrupt nesting (basically we enable the hwip to take in any new interrupts if present).

4. So this is the place where the interrupts are nested.

Could you tell me how you are testing the nesting?

We do have an example that we can provide to show interrupt nesting in no rtos.

Hope this helps.

Thanks & Regards

Sri Vidya

Hi Sue

Got it. Thanks for the reply.

Could you also please respond to the below details:

Are you able to see the prints on console for both the interrupts? The DebugPLog API which is used to print is disabled inside an ISR.

Sue A said:

interrupt 1 ==> int num = 146 (from R5FSS0 CORE0 interrupt map), priority = 3, level triggered

May be your Interrupt ISR is being executed quickly before the next high priority interrupt comes?  You can Add GPIO toggle to see the code flow of execution between ISR1 and ISR2.

About interrupt prioritization:

The interrupt prioritization example also shows interrupt nesting. Are you able to execute this example in your setup?

Nesting of interrupts is shown with the help of trace buffer which captures the start and end of each Timer ISR.
This example configures Timer 0, 1, and 2 interrupt priority in SysCfg with timer 0 priority being highest and timer 2 being lowest and prints a trace for the order of execution. Timer2 is started first followed by Timer1 and then Timer0. Timer2 Interrupts gets nested by Timer1 interrupt which in turn gets nested by Timer0 interrupt.

Sue A said:

interrupt 1 ==> int num = 146 (from R5FSS0 CORE0 interrupt map), priority = 3, level triggered

About interrupt nesting using EPWM and GPIO toggle:

What peripherals are you using for setting the interrupts? Is it like EPWM?

Here is another example for interrupt nesting:

Below is an example I have done with EPWM interrupts to show interrupt nesting. 

I Have two EPWM Interrupts as shown below:

Both the EPWM interrupts are configured for pulse interrupts.

EPWM 1 ISR priority --> 4

EPWM 2 ISR priority --> 3

EPWM1 and EPWM2 have same time period. But EPWM1 counter is started before the EPWM2 So the EPWM1 is always ahead of EPWM2.

The code flow is below:

1. First the ISR1 is executed as EPWM1 is always ahead of EPWM2.

2. EPWM1 ISR has some delay added in the form of FOR loop So the code stays in ISR1.

3. When EPWM2 ISR is trigger this is pre-empted as it has high priority.

4. Now EPWM2 ISR finishes execution, then goes back to EPWM1 to finish the ISR execution.

I am toggling GPIOs in both the ISRs to see this flow:

Hope this helps

Regards

Sri Vidya

Hi 

Sue A said:

When I give higher priority to ISR1, I see ISR1 executing first and after ISR1 completes execution, ISR2 executes.

Yes this is expected.

Since ISR1 is highest priority, ISR2 is started only when ISR1 execution is completed.

Sue A said:

It seems like ISR2 always executes first because of its higher priority.

So to check the nesting, your ISR2 needs to be high priority than ISR1. But ISR1 has to start execution first compared to ISR2. I suggest you to Start your ADC SOC at TBCTR > 60 to see that the nesting is visible through GPIOs. I have explained the reason below:

From the picture you have sent, it looks like ISR2 is indeed nested in ISR1.

ISR Latency:

ISR interrupt latency is approximately 415 nsec --> This is the time taken between the ISR trigger and the actual Application ISR execution start.

ADC Hardware Conversion Latency:

I see that your ADC start of conversion is also happening at TBCTR = 0.

ADC Sample Window is 16 Sysclock cycles.

The core requires approximately 10.5 ADCCLK cycles to process a voltage into a conversion result.

The ADC End of Conversion --> SOC1 starts after SOC 0 is done. Refer section 7.4.2.6 ADC Conversion Priority in TRM for more information.

The above two latencies cannot be seen through GPIO toggle. I suggest you to Start your ADC SOC at TBCTR > 60 to see that the nesting is visible through GPIOs.

Hope this helps

If it doesn't work, I will also try at my end. Could you also let me know why is the need to nest ISR2 inbetween ISR1?

Regards

Sri Vidya