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.

What happens in ISR when triggers very frequently

Genius 3300 points
Other Parts Discussed in Thread: TM4C123GH6PM

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

  • 3. I think what's happening here, before control gets out of ISR, another interrupt happens.

    Almost there.

    Check the Cortex M4 core reference manual, what the core does at interrupt entry and exit. By adding up this instructions, including that one's to acknowledge the interrupt, you can calculate the saturation frequency of your MCU. At this interrupt frequency, the core needs 100% of available performance to enter/leave the interrupt.  And if you go up even further, it spends 100% performance inside that interrupt handler. And needless to say, that will break your application logic.

  • Also note that pins do not change state instantly and that the core cannot always execute at full speed.

    Robert
  • You are correct - I assumed that "too much information" might also overload the OP.

    But specifically, I would like to point there for reference (ARM DDI 0439B, ID030210) - see "section 3.9.1 Exception handling".

  • @f.m. & Robert,

    Great job fellows - a properly appreciative poster - surely will be pleased.

    Might there be yet another principle which may be teased from this recital?   While well motivated - the experimentation registered as (almost) "blind."   (i.e. w/out full read/review of the ARM defined references)   

    The best experimentation reads/reviews key/critical data/instructions first (so often - avoids unpleasantness) and launches experimentation only later...

  • The best experimentation reads/reviews key/critical data/instructions first (so often - avoids unpleasantness) and launches experimentation only later...

    This seems to be an "outdated" strategy, prevalent amongst "IT dinosaurs" like us, stemming from ancient times with no / very slow internet and hardcopy examples. Downloading/building/running example code is nowadays so much faster than reading manuals (and "thinking") ...

  • I have read your (clearly true) comments just before (jumping) from this tall building...

    Fortunately - as a "for profit" enterprise - staff + this reporter, "RTFM" (and even beyond...i.e. potentially related docs) as, "Wheel re-invention, missed (yet known) errata or rules of the MCU road" costs time, money, effort and morale.

    Let the dinosaurs (or at minimum their "way") return...   Guaranteed to "soften" unpleasant landings.   (my chute properly opened...)