How Is An Interrupt Service Routine Different From A Subroutine In Terms Of Register Usage

Summary

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

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

Interrupt Code Example (in C)
General Exception Code Example (in C)

Overview

PIC32MX CP0 and Interrupt Controller registers are initialized by hardware and MPLAB^® XC32 Compiler start-up code placing the Central Processing Unit of measurement (CPU) in the post-obit country upon entry to your primary() function:

Ebase = _ebase_address (= 0x9FC01000 for PIC32MX795F512L)

IntCtl_VS<4:0> = 0x01 (Vector spacing is initialized to 32 (0x20) bytes (viii words) betwixt entry points)

Status_BEV = 0 (Exception vector entry points changed from the "bootstrap" location to the "normal" location)
- General Exceptions: Ebase (= 0x9FC01000) + 0x180
- Interrupt Exceptions: Ebase + 0x200 + (VectNumber * IntCtl_VS)

Status_IE = 0 (Interrupt Exceptions Disabled)

Status_IPL<ii:0> = 0 (CPU running @ priority level 0)

INTCON_MVEC = 0 (Interrupt controller configured for unmarried-vector mode)

Prefetch Cache is disabled

PFM Expect States = seven (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 dissimilar to an ordinary role in that it handles the context salve 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.

At that place are several actions that the compiler needs to accept to generate an interrupt service routine:

The compiler has to be told to use an alternate form of render code.
The compiler has to exist told whether to employ 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 lawmaking for an ISR ( __ISR() macros are provided so that this is easier to attain).

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

An awarding 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 volition now exist more fully described.

_INT_VECTOR_NUMBER

Unique Vector Number Identifier, equally shown in Table 7-1 in the device information sheet:

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

IPLx[SRS|SOFT|AUTO]

Assign Interrupt priority level (0-7) to the ISR, and
Ascertain how context is preserved
- The generated lawmaking preserves context by either using the shadow register set (SRS) or using generated software instructions (SOFT) to push context onto the stack.
- Motorcar setting tells the compiler to use the run-time value in CP0 register SRSCtl to make up one's mind whether it should employ 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 render values are allowed on an ISR.

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

Case

In this example, nosotros ascertain a Timer 2 ISR role T2Interrupt() that is configured as a IPL-level-7 process, and to which is assigned the shadow-register ready (as defined by the DEVCFG3_FSRSSEL<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 annals (PRx) that, when properly initialized, will periodically trigger a Timer interrupt request signal in an IFSx annals as shown:

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

Footstep 4. Configure Interrupt Controller

The side by side step is to configure the associated Interrupt Controller Flag, Enable and Priority settings for the specific interrupt. In this example, those registers/$.25 associated with Timer two interrupt events:

IPC2 Register
- Contains Timer 2 interrupt priority bits
IFS0 Register
- Contains Timer two interrupt request bit
IEC0 Annals
- Contains the Timer 2 interrupt enable scrap

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

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

Footstep 5. Assign The Shadow Register Ready to an IPL

The PIC32MX has 1 shadow annals gear up that tin be used for whatsoever priority level, eliminating software context switch and reducing interrupt latency.

If y'all assign a shadow register gear up to an interrupt handler function (every bit in our case), you must also initialize the DEVCFG3_FSRSSEL<2:0> (Device Configuration Discussion 3) fleck settings.

The following example initializes DEVCFG3_{FSRSSEL<two:0>} and then that the shadow register sets is assigned to interrupt priority level 7.

All iii steps must be followed to properly configure shadow register functioning:

Device configuration bits
ISR Definition
Peripheral IPCx register setting

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

Footstep half-dozen. Set Interrupt Controller Fashion

Next, we demand 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 INTCON_MVEC bit.

MPLAB^® XC32 provides a nice macro that can be applied with the INTCONSET annals as shown in the following instance:

Pace seven. Enable Interrupt Exceptions

Next, we need to globally enable interrupts past setting the CP0 Status_IE bit.

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

Stride 8. Enable Peripheral

Finally, we trigger the generation of interrupt exceptions past enabling the peripheral(south):

Code Case - Interrupt Usage

All preceding steps for interrupt exception usage are combined in a consummate working MPLAB^® X IDE projection:

Interrupt Code Example (in C)

General Exception Usage

PIC32 devices also take 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 lawmaking is running (Status_BEV=i).

All Reset exceptions are vectored to 0xBFC00380.

At this location, the 32-bit toolchain places a co-operative 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.thou., _attribute_((nomips16))], since the beginning-upwardly code jumps to this function.

Full general Exception

A general exception is whatever non-interrupt exception which occurs during programme execution outside of bootstrap lawmaking (Status_BEV=0).

Full general exceptions are vectored to Ebase + 0x180.

At this location, the 32-fleck toolchain places a branch education targeting a part 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 pedagogy.

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

If the user awarding 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 lawmaking 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 :

General Exception Code Example (in C)