Configuring Interrupts and Exception Handling on Cortex-M1

The Cortex-M1 processor from ARM is a 32-bit RISC processor optimized for microcontroller applications. It supports advanced interrupt handling and configurable prioritized exception handling to meet real-time system requirements. Proper configuration of interrupts and exceptions is critical for developing robust and responsive Cortex-M1-based systems.

Cortex-M1 Interrupt Architecture

The Cortex-M1 processor provides extensive support for fast, deterministic interrupt handling through its Nested Vectored Interrupt Controller (NVIC). The NVIC supports up to 240 external interrupt sources with configurable priority levels. It also handles a number of internal exceptions such as memory faults, bus errors, and supervisor calls. The NVIC includes an interrupt controller, vector table, and peripheral control registers.

When an interrupt or exception occurs, the processor suspends execution of the current code and jumps to a corresponding vector in the vector table. Each vector contains the memory address for an interrupt service routine (ISR) specific to that interrupt source. The NVIC allows assign priority levels to interrupts to determine the order in which nested interrupts are handled. Higher priority interrupts can preempt lower priority handlers.

The Cortex-M1 processor has five types of exception and interrupt vector locations:

• Reset Vector – Points to startup code executed on reset
• NMI Vector – Handles non-maskable interrupts like memory faults
• HardFault Vector – For errors during exception processing
• SVC Vector – Entry point for supervisor calls
• Interrupt vectors – One for each external interrupt source

Configuring NVIC in Cortex-M1

The NVIC registers are used to configure interrupt and exception handling in Cortex-M1. This includes settings like:

• Interrupt enable/disable for each external interrupt
• Priority grouping to set preemption threshold
• Priority level for each interrupt
• Vector table offset register to relocate vector table

These registers can be accessed using special register access instructions in code or through a debug probe. Here are some key steps for setting up the NVIC at runtime:

1. Configure priority grouping – Groups priority bits to configure preemption
2. Set priority levels for interrupts
3. Enable required interrupt sources
4. Optionally change vector table offset
5. Clear pending interrupts before enabling

The NVIC grouping registers specify how the 8-bit priority field for each interrupt will be split into preemption priority and subpriority bits. For example, a grouping of 0x05 means 3 bits for preemption priority and 5 bits for subpriority. This determines the relative priority of interrupts when multiple interrupts are pending simultaneously.

The NVIC also contains Interrupt Set Enable Registers (ISERn) to enable each external interrupt indexed from 0 to 239. By default all interrupts are disabled after reset and must be explicitly enabled by setting the corresponding bit in the ISERn registers. Similarly, the Interrupt Clear Enable Registers (ICERn) can disable enabled interrupts by clearing bits.

Configuring Interrupt Service Routines

An interrupt service routine (ISR) is a software routine that executes when a particular interrupt or exception vector is invoked. The Cortex-M1 vector table must be populated with addresses pointing to ISR functions for supported interrupts. Here are some ISR implementation guidelines for Cortex-M1:

• ISR code must be placed in RAM, not flash memory
• Minimize ISR execution time to avoid latency
• Use stack frame registers to maintain context
• Clear pending status for interrupt at end of routine
• Return using exception return instructions

The ISR typically starts by saving context like registers and CPU status onto the stack. The exception return instructions at the end of the ISR restore context so execution can resume where it left off. Using stack frame registers provided by Cortex-M improves context switching during nested exceptions.

Here is an example outline for an interrupt service routine: void ISR_NAME(void) { // Save context onto stack // Clear pending status flag for this interrupt // Perform interrupt handling // Restore saved context // Return from exception }

It is important to clear the pending status flag for the interrupt at the end of the handler. Otherwise it will keep triggering infinitely. The return instruction restores the stack pointer and program counter registers to exit the routine cleanly.

Setting Up Cortex-M1 Vector Table

The Cortex-M1 vector table defines the entry points for various exception and interrupt handlers. It must be aligned to a 256 byte boundary. A typical vector table setup for Cortex-M1 looks like: __Vectors: .word __startup /* stack pointer on reset */ .word Reset_Handler /* reset vector */ .word NMI_Handler /* NMI handler */ .word HardFault_Handler /* hard fault handler */ … .word IRQ10_Handler /* interrupt 10 */ … .word IRQ239_Handler /* interrupt 239 */

The reset vector points to startup code that configures the stack pointer, initializes data sections, and calls the main application. The remaining vector addresses can point directly to ISR functions or dispatchers that call specific handlers. The table size is 256 words (1KB) supporting up to 240 external interrupts.

The NVIC vector table offset register (VTOR) specifies the base address of the vector table. This can be changed to relocate the vector table anywhere in system memory at runtime.

Exception Handling in Cortex-M1

Exceptions in Cortex-M1 include errors like undefined instructions, memory faults, divide by zero, etc. Some exceptions have configurable priority while others are fixed priority system exceptions. When an exception occurs:

1. Current execution state is saved to stack
2. Exception handler runs based on vector
3. Handler execution completes
4. Saved state is restored
5. Execution resumes from point of exception

The HardFault exception acts as a catch-all for exceptions that don’t have specific handlers. HardFaults should trigger an error or halt execution. Logging exception details like stack frame and fault status registers helps debug issues.

Some guidelines for Cortex-M1 exception handling:

• Implement handlers or schedule errors for unsupported exceptions
• Configure usage faults for catching common software bugs
• Handle exceptions locally if possible before escalating
• Use stack frame registers for efficient context save/restore
• Log fault status information to help debugging

Advanced exception handling features like configurable stack overflow, state dumping for post-mortem analysis, and selective vector catch for debugging require debug probe assistance and are beyond the basic Cortex-M1 capabilities.

Using Interrupts Efficiently in Cortex-M1 Systems

Here are some design practices to use interrupts effectively in Cortex-M1 applications:

• Minimize context switching – Keep ISR code as short as possible
• Avoid processing delays – Defer non-critical background work if needed
• Use priorities wisely – Favor disabling over priority lowering
• Utilize peripherals – Offload processing to peripherals if possible
• Sleep when idle – Use WFI instruction to conserve power
• Validate arguments – Check inputs to avoid exceptions in ISRs

Profiling ISR execution time and scheduling delays can help identify opportunities for optimization. For time-critical applications, bare-metal designs without operating system may be preferred to minimize interrupt latency.

In designs with multiple peripherals, use separate interrupt priorities to service critical peripherals first. Assign similar priority levels to related peripheral interrupts to simplify coding.

Debugging Interrupts and Exceptions

Debugging issues with interrupt handling and exceptions on Cortex-M1 requires using a JTAG/SWD debug probe. This provides access to debug features like:

• Instruction trace and profiling
• Breakpoints
• Watchpoints
• Inspection of core and peripheral registers
• Post-mortem exception analysis

Monitoring instruction execution flow using breakpoints helps uncover issues by:

• Detecting ISR delays and synchronization problems
• Identifying exceptionally long ISR execution times
• Trapping on spurious exceptions or faults
• Halting before exception handler returns

Debug monitors can also log exception details like stack frame, LR value, fault status registers etc. for post-mortem analysis. This information is useful for diagnosing and fixing difficult hard faults or random system crashes.

Conclusion

The Cortex-M1 interrupt architecture and configurable priority exception handling enables building responsive real-time embedded systems. Utilizing its nested vectored interrupt controller optimally requires careful configuration of priority levels, exception handlers, and interrupt service routines. Following best practices for interrupt usage, vector table setup, and exception handling ensures robust system operation. With debug probe assistance, interrupt related issues can be efficiently traced and resolved during development.