All Posts

5 Tips to Better Understand Interrupt Latency in Embedded Systems

Interrupt Execution Flow

Introduction

Interrupt latency consists of the time spent from the moment the IRQ (Interrupt Request) arrives to the moment the first instruction in the interrupt handler is executed. The interrupt latency is part of the context switching process, which involves backing up the CPU state and fetching the location of the interrupt handler to jump to.

Which Parts are Involved in Interrupt Latency?

Interrupt Latency

Interrupt Latency involves:

1- CPU State Backup Routine

Cortex-m Context Switching

It consists mainly of saving CPU registers into stack memory. The impact of this process depends on the processor architecture. For instance, on Cortex-M, the backup stage is handled by hardware, resulting in a faster and more deterministic backup routine. Additionally, the type of memory used for stack context is quite important — memories with high latency can significantly increase the overall Interrupt latency.

2- Interrupting Ongoing Executed Instruction

As a general rule, a normal instruction must finish executing before an incoming IRQ request is handled. The exception to this is multi-cycle instructions, which are more complex to manage. For these, there are two models that any processor architecture can follow (with a particular focus on ARM Cortex-M processor-based architectures for benchmarking):

  1. Abandon-restart
  2. Interruptible-Continuable
  • In the first scenario, the interrupted instruction is restarted (Abandon-Restart Instruction) after the interrupt returns. This results in minimal impact on interrupt latency; however, it may create side effects, as the operation could be executed twice. On Cortex-M3, instructions such as LRDD, STRD, UDIV, and SDIV are examples of abandon-restart based instructions.
  • In the second case, the interrupted instruction is interruptible-continuable, as seen with multi-cycle instructions (STM, LDM, PUSH, POP) in Cortex-M4, M7, and M0+. This means that the instruction will be interrupted, and its execution state will be backed up before serving the IRQ request. Upon return from the ISR routine, the execution state will be restored, allowing the instruction to resume execution from the point where it was interrupted. This is the ideal scenario, as it has minimal impact on interrupt latency and does not create side effects like re-executing the instruction twice.

3- Vectored and Non-Vectored Interrupt Handlers Model

Vectored interrupts mean that each IRQ line has its own interrupt handler routine. This model is considered to have the lowest possible latency, as the hardware manages everything related to interrupt acknowledgment and fetching the corresponding ISR handler routine.

The non-vectored model means we have a single routine that serves as the entry point for all interrupt routines. In this case, we need to write software to determine the correct IRQ number that triggers the jump to the interrupt routine, followed by acknowledging the ISR through software. While this model incurs higher latency, it does not require the complex hardware logic necessary for the vectored model.

4- Interrupt Vector Table Location Impact

Upon receiving an IRQ request, the processor must locate the interrupt handler to which it will jump. First, it needs to find the interrupt vector table and then parse this table to fetch the corresponding ISR routine handler. If the interrupt vector table is located in high-latency memory, this will increase overall interrupt latency. Conversely, if it is located in low-latency memory, the overall interrupt latency will decrease.

5- System Bus Interconnect Arbitration and Load Impact

Before even reaching the CPU backup stage, and while the ongoing instruction is either finishing execution or being interrupted, the decision to serve the incoming IRQ request depends on the current load of the bus interconnect and the arbitration model it is employing. As a result, servicing the IRQ may be delayed until it receives sufficient prioritization from the bus arbitration, which can significantly increase overall interrupt latency.

Conclusion

Cortex-m Interrupt Latency

As we can see, interrupt latency is an important concept that can significantly impact overall application performance, especially if the application involves heavy context switching routines. Therefore, understanding the factors involved in this concept and minimizing the impact of each factor will enhance overall application performance. The ultimate advice is to break down any complex concept into smaller parts and tackle each one separately to achieve the best impact on the overarching concept. Interrupt latency serves as a valid use case for this methodology!