PIC32MZ Interrupt and Exception Usage


PIC32MZ Interrupt and Exception operation must be carefully initialized by the application developer. This page summarizes the key initialization & 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)


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

  • Ebase = _ebase_address (= 0x9D000000 for PIC32MZ2048ECG100)
  • OFFx registers are initialized by start-up code based on defined ISRs in your project
  • StatusBEV = 0 (Exception vector entry points changed from the "bootstrap" location to the "normal" location)
    • General Exceptions: Ebase (=0x9D000000) + 0x180
    • Interrupt Exceptions: Ebase + OFFx
  • StatusIE = 0 (Interrupt Exceptions Disabled)
  • StatusIPL<2:0> = 0 (CPU running @ priority level 0)
  • INTCONMVEC = 0 (Interrupt controller configured for single-vector mode)

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)

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


  • Macro for defining an interrupt service routine such that the entire handler is placed at the vector address.

This macro is especially useful in PIC32MZ devices which feature variable vector offsets. The compiler calculates the required vector spacing and initializes OFFx registers accordingly.


  • Unique Vector Number Macro from the device header file. Also listed in table 7-2 of the device data sheet as "XC32 Vector Name":


  • Assign Interrupt priority level (0-7) to the ISR, and
  • Define how context is preserved
    • The generated code preserves context by either using a shadow register set (SRSy) or using generated software instructions (SOFT) to push context onto the stack.

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


  • Unique name you give the ISR.

NO parameters are allowed on an ISR. NO return values are allowed either.



In this example, we define a Timer 2 ISR function T2Interrupt() that is configured as a IPL-level-4 process, and which will use shadow-register set #3 (as defined by the PRISS register setting):

Step 3. Configure Peripheral

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

For example, PIC32MZ 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:


In this example, we will initialize Timer2 to generate interrupt requests every 100mS, given PB3CLK of 8 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 Shadow Register Sets to IPLs

The PIC32MZ has 7 shadow register sets 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 PRISS (PRIORITY SHADOW SELECT) register.

The following example initializes PRISS so that shadow register sets 1-7 are assigned to interrupt priority levels 1-7 respectively.

Setting PRISS = 0x76543210; guarantees that each user interrupt priority level will have its own dedicated shadow register set.

Assigning a shadow register in an ISR definition without properly configuring PRISS will produce unpredictable behavior.

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

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 it's 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.