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

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);    
  
}

 

Google interrupt latency.essentially the overhead get into an use, before your code is executed.

Typically 10 to 20 ticks but can be more or less.

 

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?

It will only happen once since you clear the interrupt flag when servicing the ISR. If your timer has run around multiple times, you lose those tiks.

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

I think you're right. The ISR takes a certain number of cycles to execute. The timer can't run faster than the ISR execution time or you lose tiks. That's why its important to do minimal processing in the ISR. Keep in mind, too, that the more stuff you do in the ISR, the more context (arithmetic registers etc) has to be saved/restored before any interrupt processing can begin.

Note that some processors support multiple interrupt levels which can help but you still need to get through the service routine - on average - in a shorter time than the interrupt requests.

I'm not familiar with your particular processor but most IDEs have a 'stopwatch' or other profiling function that will report the time / number of cycles spent in an interrupt routine. That plus examining the compiler's assembler output can be most helpful.

Some compilers support 'back tail processing' in ISRs which, after servicing an interrupt, loops back to the top and rechecks for any new pending interrupts to service before restoring context and returning. That saves the time of restoring/returning from an ISR only to have to immediately do it all again when interrupts are re-enabled.

 

When an interrupt condition happens it sets a flag. It is said that the interrupt is pending. It'll be pending until processed. When the interrupt gets processed it clears the flag.

If another interrupt condition happens while the previous interrupt is still pending, it sets the flag, but since the flag is already set, this has no effect. Therefore, it gets lost.

However, the effect you observe does not have much to do with how interrupts work. Starting with a certain frequency, you simply get back-to-back executions of your "systic_isr_handler" routine + some overhead. One execution takes 200ns. Therefore, no matter what you do, or how interrupts work, you can only execute your routine 5 million times per second, not a bit more. Thus your frequency is limited at 5MHz.

You can experiment and run your routine in a "while(1)" loop instead of the interrupt and measure the frequency. Then you can tell how much more (or less) is the interrupt overhead compared to looping overhead.