What are the interrupts and exceptions in Cortex-M3?

The Cortex-M3 processor has a number of interrupts and exceptions that allow it to respond to events and handle errors gracefully. Interrupts are signals generated by hardware peripherals or software that cause the processor to suspend execution of the current program and run an Interrupt Service Routine (ISR) to handle the event. Exceptions are errors or exceptional conditions that arise during execution, like illegal instructions or divide by zero, that transfer control to an Exception Handler to deal with the problem before continuing. This article provides an overview of the different interrupts and exceptions in the Cortex-M3 and how they can be used in application development.

Interrupts

Interrupts allow the processor to respond to external or internal events in real-time without the need for constant polling. When an interrupt occurs, the current program counter and processor status are saved, and execution jumps to a predetermined interrupt handler function. Once the interrupt handler finishes, execution resumes where it left off. There are 240 interrupt sources in total in the Cortex-M3 processor. The interrupts are grouped into the following categories:

External Interrupts

These are hardware interrupts generated by external peripherals like timers, GPIO, serial interfaces, etc. The Cortex-M3 supports up to 208 external interrupts assigned to the NVIC (Nested Vectored Interrupt Controller). NVIC allows nesting of interrupts, so higher priority interrupts can interrupt lower priority ISRs. External interrupts are enabled by configuring the NVIC registers.

Software Interrupts

These are interrupts triggered by software using the SVC instruction. This performs a call to the SVCall handler. Software interrupts are useful for implementing OS functionality like task switching or entering low power mode. Only one software interrupt is available (SVCall).

Debug Interrupts

These facilitate debug and trace functionality. For example, breakpoints and watchpoints trigger the DebugMonitor interrupt. Up to 16 debug interrupts are available.

PendSV and SYSTICK

PendSV (Pendable Service Call) and SYSTICK (System Tick Timer) are two special interrupts with dedicated exception entries. PendSV is similar to SVCall but has lower priority. It is used for OS task switching and housekeeping functions. SYSTICK provides a countdown timer for real-time OS tick generation.

Exceptions

Exceptions are synchronous events triggered by the processor itself in response to an instruction execution error or other exception conditions. When an exception occurs, execution jumps to the corresponding exception handler. Common exceptions include:

Reset

This causes processor boot-up after power-on. It initializes registers and starts execution at the reset vector address.

NMI (Non Maskable Interrupt)

NMI indicates an unrecoverable hardware error. It cannot be disabled by software. The NMI handler can perform recovery actions or graceful system shutdown.

Hard Fault

Hard fault occurs because of an error during exception processing. It indicates serious issues like a bus error or corrupted stack. Hard faults usually require a system reset to recover.

MemManage

This fault occurs on MPU violations, like invalid memory access permissions or misaligned accesses. The fault handler fixes MPU configurations or refactors the code.

Bus Fault

Bus faults result from invalid external memory accesses like an incorrect address or missing device. The handler checks addresses and clock configurations.

Usage Fault

This fault can be triggered by undefined instructions, invalid EPSR state, or unaligned data access. The handler fixes software bugs causing these issues.

Debug Monitor

As the name suggests, this exception is raised on debug events like breakpoint match, watchpoint match, etc. It is used internally by the debugger.

SVC

This is triggered by the SVC instruction for handling software interrupts. The SVC handler runs user-defined code.

Configuring Interrupts and Exceptions

Handling interrupts and exceptions involves the following steps:

1. Enable the interrupt source by configuring the appropriate NVIC register (external interrupts only)
2. Write the interrupt/exception handler functions and define them in the vector table
3. Initialize stack pointers and priority levels as needed
4. Include __wfi instruction in the main code to sleep the processor until the next interrupt

When an interrupt or exception occurs:

1. Processor context is saved and execution jumps to the handler
2. The handler runs and services the routine
3. The handler finishes with an appropriate return instruction
4. Context is restored and code execution resumes from where it left off

This allows seamless integration of real-time response to events alongside the main application software flow. The Cortex-M3 documentation provides specific details on the vector table, NVIC registers, and exception handling process. Developers should leverage interrupts and exceptions appropriately to build robust embedded applications.

Use Cases

Here are some examples of how interrupts and exceptions are used in practical Cortex-M3 applications:

External Interrupts

• Timers – Generate periodic interrupts for real-time clock, alarms, PWM output, etc.
• GPIO – Switch press or external signal interrupts to trigger user actions
• UART – Data received interrupt to process serial data
• SPI/I2C – Frame/transfer complete interrupt signaling communication events

Software Interrupts

• OS task switching – PendSV for cooperative task switching
• OS tick counter – SYSTICK interrupt triggers the RTOS tick
• Enter low power – SVC call to wake up and sleep the CPU on demand

Exceptions

• Hard Fault – Gracefully log error and reboot
• Bus Fault – Detect invalid external bus access and handle errors
• Debug Monitor – Breakpoint match suspends execution and enters debug
• SVC – OS uses SVC for syscalls and scheduling

Tips for Effective Implementation

• Assign higher priority to time critical and important interrupts
• Keep ISR code short, fast and atomic
• Avoid resource contention between main code and ISRs
• Return from handler using tailored return instructions like RETI
• Mind stack usage by ISRs and allow enough headroom
• Utilize CPU sleeping and wake on interrupt to conserve power
• Debug exceptions to identify software bugs
• Disable or reconfigure a peripheral causing unwanted interrupts

Conclusion

Interrupts and exceptions enable Cortex-M3 microcontrollers to respond to real-time stimuli and handle abnormal events respectively. Interrupts are triggered by hardware or software and catered to by ISRs, while exceptions arise from erroneous conditions and are handled by specialized exception handlers. Both mechanisms allow the processor to deviate from sequential code execution and run specific subroutines to manage various situations. Configuring and utilizing interrupts and exceptions judiciously allows developers to build responsive and robust embedded applications on the Cortex-M3 platform.