What happens in ISR when triggers very frequently

[Vindhyachal.takniki]

1. I have made a SYSTICK interrupt in TM4c123GH6PM. CPU speed is at 80Mhz. Code is below. In systick interrupt a led is toggled. Code is build with full speed optimization. CRO probe is at 10x & peak detect setting is done in CRO.
2. I have started by Systick period value 8000000 i.e 100ms, pulse ON CRO is exact, then I keep on decrease the period by decade factor.
   8000000 i.e 100ms works fine,   (visible led blinking here)
   800000 i.e 10ms works fine,     (visible led ON from here, led turn/off fast so cannot observe off)
   80000 i.e 1ms works fine,       
   8000 i.e 100us works fine,     
   800  i.e 10us works fine.       
   80 i.e 1us works fine.         
   8 i.e 100ns.       (Here pulse on or off time recorded is 200ns around instead of 100ns) 
   1 i.e 12.5ns.  (Again 200ns time of pulse on or off)             
   
3. I think what's happening here, before control gets out of ISR, another interrupt happens. So waht happens, let say control takes lots of time in ISR & in meantime systick timer rolls off 10 times. So will interrupt will again execute 10 times after that or only once?

4. Why even at 12.5ns of systick time, toggle taking 200ns. I think there are 16 number of cycles for PUSH so that when isr happens & control actually goes into interrupt. It makes 16*12.5 = 200ns. But then there is also POP involved & ISR instruction execution. How to explain this delay

Code: [Select]

void systic_isr_handler(void)
{
    RED_LED_INVERT();
} 
 
 
 
 
void all_tasks_manager(void)
{   
/* clear any previous interrupt */ 
    SysTickDisable();
    SysTickIntDisable();
 
/* resgister the int */ 
    SysTickIntRegister(systic_isr_handler);
    SysTickIntEnable();
 
 
    SysTickPeriodSet(2U);
    SysTickEnable();
 
    while(1);   
 
}
 

[mikerj]

3. I think what's happening here, before control gets out of ISR, another interrupt happens. So waht happens, let say control takes lots of time in ISR & in meantime systick timer rolls off 10 times. So will interrupt will again execute 10 times after that or only once?

No it will only run once.  There is only a single interrupt flag for the Systick timer, there's no FIFO buffer to store previous unserviced interrupts.

4. Why even at 12.5ns of systick time, toggle taking 200ns. I think there are 16 number of cycles for PUSH so that when isr happens & control actually goes into interrupt. It makes 16*12.5 = 200ns. But then there is also POP involved & ISR instruction execution. How to explain this delay

It sounds like you are guessing.  Look at the disassembled code for your interrupt routine and see what instructions the compiler has actually generated.  Also note that the Cortex M4 has a lazy stacking feature that means some registers are pushed onto the stack during the 12 cycle interrupt latency - if no other registers are needed then there will be no additional overhead used in pushing them onto the stack.

[hamdi.tn]

And if an interrupt is triggered so frequently it can prevent lower priority interrupt from being executed (totally or partially) and the main routine too

[Jeroen3]

Look at the assembler of the ISR to know what your compile has come up with.
It probably only does 1 push/pop. (R0)

When the ISR is launched, only higher priority interrupts can preempt. Read the manual if you want to know exactly how that works.

[Kleinstein]

Looks like the ISR takes around 200 ns to execute. If set for a higher frequency you just see the runtime of the ISR, as there is always an interrupt request waiting when the ISR is finished.

[newbrain]

4. Why even at 12.5ns of systick time, toggle taking 200ns. I think there are 16 number of cycles for PUSH so that when isr happens & control actually goes into interrupt. It makes 16*12.5 = 200ns. But then there is also POP involved & ISR instruction execution. How to explain this delay

The actual interrupt latency, as other have reported, is (for 0 wait states memories plus some other conditions) 12 cycles, as the pushing of the state and the vector fetching can happen simultaneously on two different buses.

That said:

Also note that the Cortex M4 has a lazy stacking feature that means some registers are pushed onto the stack during the 12 cycle interrupt latency - if no other registers are needed then there will be no additional overhead used in pushing them onto the stack.

The lazy stacking is actually related to the FPU registers, what is happening here is the so called "tail chaining" of interrupts: since an interrupt request is pending by the time the ISR ends, the stacked register are not popped at all (they would have to be immediately pushed again) and only the IRQ vector is fetched, bringing down the latency to 6 cycles (M3 link: it is more extensive, but applies to M4 too). ISR exit adds a further 6 cycles.

With that in mind, you can follow the advice of looking to the generated assembler.