PIC32MX Interrupt and Exception Usage

 Summary

PIC32MX Interrupt and Exception operation must be carefully initialized by the application developer. This page summarizes the key initialization and usage steps required for both interrupt exceptions and general exceptions.

Further information regarding interrupt and exception usage is provided by the MPLAB® XC32 User's Guide (DS50001686)

Overview

PIC32MX CP0 and Interrupt Controller registers are initialized by hardware and MPLAB® XC32 Compiler start-up code placing the Central Processing Unit (CPU) in the following state upon entry to your main() function:

  • Ebase = _ebase_address (= 0x9FC01000 for PIC32MX795F512L)
  • IntCtlVS<4:0> = 0x01 (Vector spacing is initialized to 32 (0x20) bytes (8 words) between entry points)
  • StatusBEV = 0 (Exception vector entry points changed from the "bootstrap" location to the "normal" location)
    • General Exceptions: Ebase (= 0x9FC01000) + 0x180
    • Interrupt Exceptions: Ebase + 0x200 + (VectNumber * IntCtlVS)
  • StatusIE = 0 (Interrupt Exceptions Disabled)
  • StatusIPL<2:0> = 0 (CPU running @ priority level 0)
  • INTCONMVEC = 0 (Interrupt controller configured for single-vector mode)
  • Prefetch Cache is disabled
  • PFM Wait States = 7 (max. setting)
  • Data Ram Wait States = 1 (max. setting)

The following steps must be taken in the application code for proper interrupt exception initialization & usage.

Step 1. #include Standard Headers

The application must include header files xc.h and attribs.h as shown below:

The <sys/attribs.h> header file provides macros intended to simplify the application of attributes to interrupt functions:

  • _ISR(V, IPL)
  • _ISR_AT_VECTOR(V, IPL)

There are also Vector Number macros defined in the processor header files (included via <xc.h>) - see the appropriate header file in the compiler’s /pic32mx/include/proc directory.

Step 2. Provide Interrupt Service Routine (ISR)

An interrupt handler function is different to an ordinary function in that it handles the context save and restore to ensure that upon return from interrupt, the program context is maintained. A different code sequence is used to return from these functions as well.

There are several actions that the compiler needs to take to generate an interrupt service routine:

  • The compiler has to be told to use an alternate form of return code.
  • The compiler has to be told whether to use a shadow register set for context save/restore.
  • The function needs to be linked to the interrupt vector.

Several function _attributes_ are provided to allow the application developer to define ISR handlers so that the compiler generates the correct code for an ISR (__ISR() macros are provided so that this is easier to accomplish).

For all interrupt vectors without specific handlers, a default interrupt handler will be installed. The default interrupt handler will reset the device.

An application may override the default handler and provide an application-specific default interrupt handler by declaring an interrupt function with the name _DefaultInterrupt.

Interrupt Service Routine Definition using the "_ISR()" Macro

The following code example shows how to use the _ISR() macro to define and interrupt function:

The various parameters will now be more fully described.

_INT_VECTOR_NUMBER

  • Unique Vector Number Identifier, as shown in Table 7-1 in the device data sheet:
int-vector-number.png
  • Macros are provided in the device header file to simplify/clarify usage. The PIC32MX795F512L header file is located here:
    • /xc32/<version>/pic32mx/include/proc/p32mx795f512l.h
int-vector-number-macros.png

IPLx[SRS|SOFT|AUTO]

  • Assign Interrupt priority level (0-7) to the ISR, and
  • Define how context is preserved
    • The generated code preserves context by either using the shadow register set (SRS) or using generated software instructions (SOFT) to push context onto the stack.
    • AUTO setting tells the compiler to use the run-time value in CP0 register SRSCtl to determine whether it should use SRS or SOFT context-saving mode.

The IPLx setting must match the interrupt controller setting (IPCx) for the specific interrupt source.

isrName

  • Unique name you give the ISR.

NO parameters or return values are allowed on an ISR.

void __ISR(_INT_VECTOR_NUMBER, IPLx[SRS|SOFT|AUTO]) isrName(void)

Example

In this example, we define a Timer 2 ISR function T2Interrupt() that is configured as a IPL-level-7 process, and to which is assigned the shadow-register set (as defined by the DEVCFG3FSRSSEL<2:0> (Device Configuration Word 3) bit settings shown):

Step 3. Configure Peripheral

Next, you must configure the peripheral to generate interrupt request events.

For example, the PIC32MX contains several Timer peripherals modules. Each module has a period register (PRx) that, when properly initialized, will periodically trigger a Timer interrupt request signal in an IFSx register as shown:

timer2-ifs-flag.png

In this example, we will initialize Timer 2 to generate interrupt requests every 100mS, given a peripheral bus clock (PBCLK) of 10 MHz (code not shown):

Step 4. Configure Interrupt Controller

The next step is to configure the associated Interrupt Controller Flag, Enable and Priority settings for the specific interrupt. In this case, those registers/bits associated with Timer 2 interrupt events:

  • IPC2 Register
    • Contains Timer 2 interrupt priority bits
  • IFS0 Register
    • Contains Timer 2 interrupt request bit
  • IEC0 Register
    • Contains the Timer 2 interrupt enable bit

Refer to the Interrupt Controller section in the device data sheet for a complete description of IPCx/IFSx/IECx registers for all interrupt sources.

In the following example, we will configure these registers; setting the initial priority level of the Timer 2 interrupt event to 4, matching the IPL setting shown in the ISR function definition below.

Step 5. Assign The Shadow Register Set to an IPL

The PIC32MX has 1 shadow register set that can be used for any priority level, eliminating software context switch and reducing interrupt latency.

If you assign a shadow register set to an interrupt handler function (as in our example), you must also initialize the DEVCFG3FSRSSEL<2:0> (Device Configuration Word 3) bit settings.

The following example initializes DEVCFG3FSRSSEL<2:0> so that the shadow register sets is assigned to interrupt priority level 7.

All 3 steps must be followed to properly configure shadow register operation:

  • Device configuration bits
  • ISR Definition
  • Peripheral IPCx register setting

This page provides more details on shadow register set operation on PIC32MX.

Step 6. Set Interrupt Controller Mode

Next, we need to configure the interrupt controller to operate in MULTI-VECTOR MODE, whereby each interrupt source is assigned to its own interrupt vector.

This setting is controlled by the INTCONMVEC bit.

MPLAB® XC32 provides a nice macro that can be applied with the INTCONSET register as shown in the following example:

Step 7. Enable Interrupt Exceptions

Next, we need to globally enable interrupts by setting the CP0 StatusIE bit.

MPLAB® XC32 provides a handy __builtin() function for this task:

Step 8. Enable Peripheral

Finally, we trigger the generation of interrupt exceptions by enabling the peripheral(s):

Code Example - Interrupt Usage

All preceding steps for interrupt exception usage are combined in a complete working MPLAB® X IDE project:

General Exception Usage

PIC32 devices also have exception vectors for non-interrupt exceptions. These exceptions are grouped into bootstrap exceptions and general exceptions.

Bootstrap (or "Reset") Exception

A Reset exception is any exception which occurs while bootstrap code is running (StatusBEV=1).

All Reset exceptions are vectored to 0xBFC00380.

At this location, the 32-bit toolchain places a branch instruction targeting a function named _bootstrap_exception_handler(). In the standard library, a default weak version of this function is provided, which merely causes a software Reset.

If the user application provides an implementation of _bootstrap_exception_handler(), that implementation will be used instead.

The handler must be attributed with the "nomips16" attribute [e.g., _attribute_((nomips16))], since the start-up code jumps to this function.

General Exception

A general exception is any non-interrupt exception which occurs during program execution outside of bootstrap code (StatusBEV=0).

General exceptions are vectored to Ebase + 0x180.

At this location, the 32-bit toolchain places a branch instruction targeting a function named _general_exception_context(). The provided implementation of this function saves context, calls an application handler function (_general_exception_handler()), restores context and performs a return from the exception instruction.

A weak default implementation of _general_exception_handler() is provided in the standard library which merely causes a software Reset.

If the user application provides an implementation of _general_exception_handler(), that implementation will be used instead.

The handler must be attributed with the "nomips16" attribute [e.g., _attribute_((nomips16))], since the start-up code jumps to this function.

Code Example - General Exception Usage

The following MPLAB®X IDE project provides a simple example of general exception setup and usage :

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.