Measuring interrupt latency on Arm Cortex-M processors

Interrupt latency is an important performance metric for real-time embedded systems built around Arm Cortex-M processors. It refers to the time elapsed from when an interrupt is generated to when the first instruction of the interrupt handler starts executing. Minimizing interrupt latency allows real-time tasks and events to be handled more responsively. This article provides guidance on measuring interrupt latency on Cortex-M devices using oscilloscopes and logic analyzers.

Overview of Interrupts in Cortex-M

The Cortex-M family of processors have a Nested Vectored Interrupt Controller (NVIC) that manages interrupts from on-chip peripherals and external sources. When an interrupt occurs, the processor finishes executing the current instruction, saves context onto the stack, and vectors to the interrupt handler. This vectoring takes several cycles and increases interrupt latency. Factors that affect vectoring time include:

• Number of interrupts already pending in the NVIC
• Stack usage at time of interrupt
• Cortex-M execution state (Thread, Handler, or Fault)

After vectoring completes, the processor fetches the first instruction of the handler from the vector table. The total time from interrupt detect to start of handler execution constitutes the interrupt latency.

Importance of Measuring Interrupt Latency

Measuring interrupt latency provides several benefits for system design:

• Verify if latency meets requirements for real-time tasks
• Compare latency of different Cortex-M variants
• Determine impact of clock speed, compiler settings, etc. on latency
• Identify parts of software stack contributing most latency
• Debug sporadic latency issues due to stack usage, number of pending interrupts, etc.

While Cortex-M data sheets provide some latency numbers, real-world measurements also depend on software and peripherals used. By measuring on actual hardware, you can characterize the interrupt response for your specific application.

Measurement Methods

Two main techniques for measuring interrupt latency are using an oscilloscope or a logic analyzer.

Oscilloscope

An oscilloscope allows visualizing timing relationships between electrical signals. To measure interrupt latency with a scope:

1. Connect scope channel 1 to the interrupt source signal
2. Connect channel 2 to a GPIO pin toggled in the first few instructions of the interrupt handler
3. Trigger scope on rising or falling edge of interrupt signal
4. Measure time from trigger to first transition on handler GPIO

This time quantifies the latency from interrupt detect to start of handler execution.

Measuring latency directly on processor pins is best. However, if pins are not accessible, triggers can also be applied to peripheral signals that generate interrupts.

To get statistically valid latency numbers, multiple measurements should be made and min/average/max values computed. The scope capture buffer size limits how many events can be captured in one run.

Logic Analyzer

For more automated measurements, a logic analyzer can capture timestamped signal transitions.

Connect logic analyzer channels to the interrupt source and handler GPIO as with the oscilloscope. Arm the analyzer, generate an interrupt, then offload timestamped data to PC for analysis.

Analyzer measurements can provide minimum, average, and maximum latency over hundreds of interrupts in one capture. Multiple threshold settings are available for precise edge triggering.

Some advanced analyzers have cross-triggering between multiple channels. This allows plotting interrupt handler entry relative to events on other processor pins like SYSTICK updates.

Measurement Circuit Examples

Here are sample circuit setups for measuring interrupt latency on Cortex-M4 and Cortex-M7 MCUs:

Cortex-M4 Measurement

The diagram below shows connection using TPIU pin to trigger oscilloscope:

1. TPIU outputs a pulse on interrupt detect
2. Handler toggles GPIO pin on entry
3. Scope measures time between TPIU and GPIO transitions

An alternative is using the SYSTICK sync signal for oscilloscope trigger.

Cortex-M7 Measurement

M7 MCUs have ARM Debug Interface v5 (ADIv5) for debug trigger outputs.

1. Connect scope to DBGRESTART signal
2. Handler toggles GPIO on entry
3. Scope measures time between DBGRESTART and GPIO

DBGRESTART pulses once per debug halt. Configure the debugger to halt on interrupt then quit halt immediately so execution continues.

Tips for Optimizing Interrupt Latency

Based on your measurements, here are some tips for optimizing interrupt latency in Cortex-M firmware:

• Minimize stack usage before interrupt occurs. This reduces time to save context.
• Disable unneeded interrupts sources to reduce pending interrupts.
• Use compiler optimizations like tail-chaining to shorten handler execution time.
• Place handlers for latency-critical interrupts at start of vector table.
• For Cortex-M7, use interrupt preemption features to reduce nesting.

Achieving low latency requires holistic optimization across software, libraries, compiler settings, and tradeoffs versus other metrics like code size.

Measurements guide iterative improvement by quantifying the impact of changes. They can reveal issues like stack overflows that degrade latency.

Conclusion

This article explained techniques for measuring interrupt latency on Arm Cortex-M processors. Key points covered include:

• Oscilloscope and logic analyzer setups for quantifying latency
• Triggering methods using processor pins like TPIU and DBGRESTART
• Generating statistics from multiple measurements
• Using metrics to guide firmware optimization

Interrupt latency impacts responsiveness for real-time embedded software. By carefully measuring latency during development, engineers can validate timing requirements and make data-driven optimizations.

Measuring on prototype hardware provides real-world characterization using the exact software configuration for a project. Arm’s Cortex-M processors provide visibility and debugging features to facilitate accurate latency measurements.

For further reading on this topic, resources like the Cortex-M7 TRM and application notes contain additional implementation details and measurement advice.

This concludes the draft article. The aim was to provide an informative overview on measuring interrupt latency, explain measurement methods, provide circuit examples, and give optimization tips based on results. Please let me know if you would like me to expand or modify the article in any way.