AN217666  PSoC™ 6 MCU interrupts  

This document assumes that you are familiar with the PSoC™ 6 MCU architecture, and application development for PSoC™ devices using the Infineon PSoC™ Creator integrated design environment (IDE) and Peripheral Driver Library (PDL). For an introduction to PSoC™ 6 MCU, see AN210781 - Getting Started with PSoC™ 6 MCU with Bluetooth® Low Energy (BLE) Connectivity. If you are new to PSoC™ Creator, ModusToolbox™, or PDL, see the References section for links to some of the available resources.

The Debugging tips section provides a few tips on finding and resolving common issues encountered while using interrupts. More complex topics are covered in Advanced interrupt topics.

CY8C61x6/7, CY8C62x6/7, and CY8C63xx devices support up to 147 system and peripherals interrupt sources.

For CM4, the 147 interrupt sources are directly mapped to its first 147 IRQ lines, i.e., INT source n is connected to IRQ n, where ‘n’ = 0 to 146. For CM0+, a 240:1 multiplexer is present in front of each of 32 IRQs and redirects any of the 147 interrupts to one of CM0+ IRQ lines. This enables any interrupt source to trigger any CM0+ IRQ.

In CY8C62x4, CY8C62x5, and CY8C62x8/A devices, the ‘N’ interrupt sources are directly mapped to the first ‘N’ IRQ lines of the CM4. The CM0+ supports 16 interrupts, of which the first 8 interrupts (IRQ 0 – 7) can be triggered by a peripheral interrupt source; the other 8 are software-triggered interrupts. One or more system interrupts (upto ‘N’) can be assigned as the interrupt source for each of the IRQ 0 - 7 lines. This allows multiple interrupt sources to be connected to the same CPU interrupt simultaneously.

The WIC block supports up to ‘W’ interrupts that can wake up a CPU from deep sleep power mode; see “Number of deep sleep-capable system interrupt sources” in Table 1.

Table 2 lists the interrupt sources that can wake a CPU from deep sleep.

There are two kinds of interrupt sources in PSoC™ 6 MCU:

• Fixed-function interrupt sources

  These are predefined interrupt sources from on-chip peripherals such as GPIO, TCPWM, SCB, and BLE Radio. Interrupts from fixed-function sources are generated from configurable events; for example, an interrupt on a rising for example signal on an input pin (GPIO), or an interrupt on a counter overflow (TCPWM).

• Universal Digital Block (UDB) interrupt sources

  UDBs consist of programmable logic devices (PLDs), datapaths, and flexible routing, which can be used to synthesize different digital functions such as Timer, PWM, UART, SPI and many more. In contrast to fixed-function interrupt sources, any digital signal generated in a UDB can trigger an interrupt. The signals are routed to the interrupt controller through the routing fabric known as Digital System Interconnect (DSI). UDB sources are available only in CY8C61x6/7, CY8C62x6/7, and CY8C63xx devices

For a complete list of interrupt sources in PSoC™ 6 MCU, see Appendix A.

PSoC™ 6 MCU has the following system Power modes: Low-Power (LP), Ultra-Low-Power (ULP), deep sleep, and hibernate. The Arm® CPU Power modes are active, sleep, and deep sleep; these are available in system LP and ULP Power modes.

In CPU active modes, CPUs execute code; all memory blocks and peripherals are available.

In all other Power modes (sleep, deep sleep, hibernate), CPU clocks are turned off and code execution is halted.

All peripherals available in active modes are also available in the sleep, deep sleep, and hibernate modes. Any peripheral interrupt, masked to the CPU, wakes up the CPU to Active mode.

Only a subset of peripherals operate in deep sleep mode. Interrupts from these peripherals cause a CPU to wake up to active mode. Table 2 lists these peripherals. Each CPU has a Wakeup Interrupt Controller (WIC) to wake up the CPU from its deep sleep mode. deep sleep wakeup functionality is supported only on the first 8 IRQs (0 to 7) on CM0+ and first ‘W’ IRQs on CM4, see Table 1.

During hibernate mode, all peripherals and clocks are turned off and only certain sources like Low Power Comparator, RTC, a dedicated WAKEUP pin, or an XRES event can wake up the device. The wakeup action is a device reset instead of an interrupt to the CPU.

For more details on device Power modes CPU sleep and wakeup behavior due to interrupts, see AN219528 – PSoC™ 6 MCU Low-Power Modes and Power Reduction Techniques or PSoC™ 6 MCU Architecture TRM.

There are two instructions that can cause the CPU to enter its sleep modes: the “Wait-for-Interrupt” [__WFI()] and “Wait-for-Event” [__WFE()]. When a WFI instruction is executed, the CPU enters sleep or deep sleep (depending on the SLEEPDEEP bit of the SCR register) and wakes up on an interrupt request (with a higher priority than the current priority level) or on debug requests. The WFE instruction is like WFI but wakes up on the next interrupt or on events like Send Event (SEV instruction), external event, or debug signals. See AN219528 for more details on sleep and wakeup instructions.

Normally, when an ISR is done executing, CPU execution returns to where it was before the ISR. PSoC™ 6 MCU supports the “Sleep-on-Exit” feature where the CPU enters or returns to sleep or deep sleep (a state similar to WFI) as soon as it completes ISR execution. As seen in Figure 5, when this feature is enabled, only one WFI instruction is needed to enter a sleep mode; the CPU returns to sleep after each ISR instead of the execution returning to main. The Sleep-on-Exit feature reduces the active cycles of the CPU and reduces the energy consumed by the stacking (PUSH to stack) and unstacking (POP from stack) of processes between interrupts. Nested interrupts are also supported when Sleep-on-Exit is enabled.

The Sleep-on-Exit feature is enabled by setting SLEEPONEXIT bit of the SCR register. There is also a PDL function available – Cy_SysPm_SleepOnExit; see Configuring interrupts using PDL for details.

ModusToolbox™ applications support both the PSoC™ 6 Hardware Abstraction Layer (HAL) and Peripheral Driver Library (PDL) libraries.

The Peripheral Driver Library (PDL) simplifies software development for the PSoC™ 6 MCU architecture. The PDL reduces the need to understand register usage and bit structures, so easing software development for the extensive set of peripherals available.

PDL API function calls are used to configure, initialize, enable, and use a peripheral driver. One such driver is System Interrupts (SysInt). SysInt provides structures and functions to configure and enable interrupt functionality. PDL also supports the CMSIS-Core libraries which include NVIC functions used for interrupt configuration.

The following steps use PDL and NVIC APIs to set up an interrupt to trigger on a signal from a peripheral.

• Configure the peripheral to generate the interrupt. For example, for a GPIO, configure the drive mode (pull up or pull down), interrupt signal generation on falling or rising edge, and unmask the interrupt. Refer to the PDL API reference documentation for your peripheral for this information
• Configure the interrupt using the structure provided by the SysInt API.

The structure is defined in the PDL SysInt driver file cy_sysint.h:

* Initialization configuration structure for a single interrupt channel */
typedef struct {        
  IRQn_Type       intrSrc;    /**< Interrupt source */
#if (CY_CPU_CORTEX_M0P)    
  cy_en_intr_t    cm0pSrc;     /**< (CM0+ only) Maps cm0pSrc device 
                                interrupts to intrSrc */    
#endif    
  uint32_t        intrPriority;   /**< Interrupt priority number (Refer to 
                                  __NVIC_PRIO_BITS) */    
} cy_stc_sysint_t;

This structure is used to configure the following (see Figure 7 for a quick summary):

• Interrupt Source (intrSrc)
  • These are the dedicated interrupt numbers as defined in the device header file (example: cy8c6247bzi_d44.h)
  • This selection depends on which CPU you want to assign the interrupt to
    • For CM4, this number represents both the interrupt number of the source as well as the CPU IRQ number. Select the interrupt number of the peripheral interrupt you wish to route to the CPU. For example, to route Port 0 GPIO interrupt, assign a value of ioss_interrupts_gpio_0_IRQn (=0).
    • For CM0+, this number represents one of the 32 multiplexers available for routing an interrupt to CM0+. Because each multiplexer is connected to a dedicated CM0+ IRQ line, use this to select the target CM0+ IRQ number. For example, to use multiplexer #4 (CM0+ IRQ#4), use “NvicMux4_IRQn” (=4).

• CM0+ interrupt number (cm0pSrc)
  • This parameter is applicable only for CM0+.
  • This represents the interrupt number of the source, which is to be routed to the multiplexer/CM0+ interrupt generator logic, selected using the intrSrc parameter. Select the interrupt number of the peripheral interrupt you wish to route to the CPU; for example, to route Port 0 GPIO interrupt, assign a value of “ioss_interrupts_gpio_0_IRQn” (=0).
• Interrupt priority (intrPriority)
  • Set the priority of the interrupt. For CM4, supported priorities are 0 to 7. For CM0+, supported priorities are 0 to 3
  Note:

  1. On CM0+, some IRQs are reserved for use by software and not available to the user. See “Configuration Considerations” under SysInt driver in PDL API reference documentation for the list of reserved IRQs
  2. On CM0+, the interrupt priority 0 is reserved for system calls

  
  

  For CY8C62x4, CY8C62x5 and CY8C62x8/A devices:

  
  
  
• Call Cy_SysInt_Init(&SysInt_SW_cfg_1, ISR_1_handler).
• Here, SysInt_SW_cfg_1 is the name of the configured structure. ISR_1_handler is the name of the interrupt handler that executes when the interrupt triggers. This function applies the routing and priority configuration of the interrupt but does not enable it
• Call NVIC_ClearPendingIRQ(SysInt_SW_cfg_1.intrSrc) to clear any pending interrupts
• Call NVIC_EnableIRQ(SysInt_SW_cfg_1.intrSrc) to enable the interrupt
• Call the _enable_irq() function to enable global interrupts. This is safe to perform as the first step, as individual CPU interrupts have not been enabled yet. You can also perform this later but interrupts are disabled at startup unless this is called

In addition to the PDL SysInt driver, the system power modes (SysPm) driver API enables the Sleep-on-Exit feature. If sleep or deep sleep mode is used in the application along with interrupts, this feature enables the firmware to keep the system in a that sleep mode almost all the time, only wake up to execute the interrupt and then immediately go back to the same sleep mode. The program does not return to the main function and stays either in the interrupt handler or in the same sleep state unless the Sleep-on-Exit feature is disabled again.

Cy_SysPm_SleepOnExit(true);

PSoC™ Creator provides a graphical interface for routing signals from peripherals to a CPU IRQ line. PSoC™ Creator provides an Interrupt (SysInt) Component. This component is a UI element on top of the SysInt PDL driver discussed in the previous section. Based on the configuration in the Component, PSoC™ Creator generates code to initialize peripherals, route interrupts, and populate the interrupt configuration structure. This reduces the amount of code you must write when setting up interrupts.

The following section shows steps to use PSoC™ Creator to configure an interrupt. See the References section for code examples.

Exceptions are the events that cause the processor to suspend the currently executing code and branch to a handler. Interrupts are a subset of exceptions. Besides interrupts, exceptions exist for operating system applications and fault handling.

Interrupt latency is defined as the time delay between the assertion of an interrupt and the execution of the first instruction in its ISR. CM0+ has a latency of 15 clock cycles (worst case); CM4 has a latency of 12 clock cycles (worst case). Some peripherals generate additional cycles due to synchronization circuit between the peripherals and CPUs. Table 3 provides the number of CPU clock cycle delays for various peripherals in PSoC™ 6 MCU.

When both CPUs are in sleep/deep sleep power mode, there is a need for additional two clock cycles required for synchronization.

Context switching affects the latency and involves the following steps:

• Current instruction execution is completed
• The processor pushes the current Program Counter (PC), Link Register (LR), Program Status Register (PSR), and some of the general-purpose registers (Program and Status Register (PSR), Return Address, Link Register (LR or R14), R12, R3, R2, R1, and R0) to the stack
• The processor reads the vector address from the NVIC and updates it to the PC
• The processor updates the NVIC registers

Thus, the latency varies depending on the current instruction being executed. To make the process efficient, both CM0+ and CM4 processors implement the following two schemes:

Tail Chaining: If an interrupt is in the pending state while the processor is executing another interrupt handler, unstacking is skipped when the execution ends for the first interrupt and the handler for the pending interrupt is immediately executed. This saves the time of restoring the registers from the stack and pushing the same registers again to stack. This is useful for nested interrupts, as seen in the following section, and for reducing the latency of low-priority interrupts.

Late Arrival: If a higher-priority interrupt occurs during the stacking process of a lower-priority interrupt, the processor jumps to the higher-priority interrupt handler instead of a lower-priority one. The processor reads the vector address of the higher-priority interrupt at the end of the stacking process. Once the higher-priority interrupt handler execution is completed, the vector address for the pending lower-priority interrupt handler is fetched and executed. This reduces the latency for a higher-priority interrupt by entering the lower priority ISR and pushing the register values to the stack.

NVIC automatically handles nested interrupts without any software overhead. If a higher-priority interrupt is asserted during the execution of a lower-priority interrupt handler, some of the general-purpose registers are pushed to stack, CPU reads the vector address from NVIC and jumps to the higher-priority interrupt handler. After the execution is completed, the processor restores the register values and execution resumes for the lower-priority interrupt.

An important performance requirement in interrupt-based applications is the ISR code execution time. In some applications, the critical code in the ISR must be executed within a particular time of receiving the interrupt request. Also, interrupt execution should not take too much time and stall the main code execution or other interrupts. To meet these requirements, use the following guidelines:

• Avoid calls to lengthy functions in the ISR. Functions such as Character LCD display routines or printing long strings to a UART terminal takes long time to execute, so blocking the execution of other low-priority interrupts. The recommended technique is to move non-critical function calls to the main code and just set a flag variable in the ISR. The main code periodically checks the flag and if set, clears it and calls the function
• Assign proper priority to the interrupts. In applications with multiple interrupts, give a higher priority to more time-critical interrupts

Although AN89610 – PSoC™ 4 and PSoC™ 5LP ARM Cortex® Code Optimization targets a different CPU architecture, it is a useful reference for general compiler topics.