# SysInt (System Interrupt)¶

group group_sysint

The SysInt driver provides an API to configure the device peripheral interrupts.

It provides a lightweight interface to complement the CMSIS core NVIC API. The provided functions are applicable for all cores in a device and they can be used to configure and connect device peripheral interrupts to one or more cores.

The functions and other declarations used in this driver are in cy_sysint.h. You can include cy_pdl.h to get access to all functions and declarations in the PDL.

Vector Table

CM0+/CM4

The vector table defines the entry addresses of the processor exceptions and the device specific interrupts. It is located at the start address of the flash and is copied by the startup code to RAM. The symbol code __Vectors is the address of the vector table in the startup code and the register SCB->VTOR holds the start address of the vector table. See Vectors Table Copy from Flash to RAM section for the implementation details. The default interrupt handler functions are defined as weak functions to a dummy handler in the startup file. The naming convention is <interrupt_name>_IRQHandler.

Defining these in the user application allows the linker to place them in the vector table in flash/ROM. For example:

void ioss_interrupts_gpio_0_IRQHandler(void)
{
...
}

And can be used like this:

/* Scenario: Vector table is not relocated anywhere from _Vectors[] in flash */

#if (CY_CPU_CORTEX_M0P)
/* Prototype of ISR function for NvicMux7, defined as a weak function in startup_psoc0x_cm0plus.s */
void NvicMux7_IRQHandler(void);

cy_stc_sysint_t intrCfg =
{
/*.intrSrc =*/ NvicMux7_IRQn,               /* CM0+ interrupt is NVIC #7 */
/*.cm0pSrc =*/ ioss_interrupts_gpio_0_IRQn, /* Source of NVIC #7 is GPIO port 0 interrupt */
/*.intrPriority =*/ 2UL                     /* Interrupt priority is 2 */
};
#else
/* Prototype of ISR function for gpio interrupt 0, defined as a weak function in startup_psoc0x_cm4.s */
void ioss_interrupts_gpio_0_IRQHandler(void);

cy_stc_sysint_t intrCfg =
{
/*.intrSrc =*/ ioss_interrupts_gpio_0_IRQn, /* Interrupt source is GPIO port 0 interrupt */
/*.intrPriority =*/ 4UL                     /* Interrupt priority is 4 */
};
#endif

/* Initialize the interrupt with vector at Interrupt_Handler_Port0() */

/* Enable the interrupt */
NVIC_EnableIRQ(intrCfg.intrSrc);

Using this method avoids the need for a RAM vector table. However in this scenario, interrupt handler re-location at run-time is not possible, unless the vector table is relocated to RAM.

CM33

CM33 with Security extension supports two vector tables, one for secure world and another for non-secure world. Secure interrupt vector table is placed in the secure ROM/FLASH, where as non-secure interrupt vector table is placed in the non-secure ROM/FLASH. In both scenarios, vector tables are copied by the startup code to secure and non-secure RAM respectively. The symbol code __s_vector_table is the address of the secure vector table and __ns_vector_table is for the non-secure world in the startup code. The register SCB->VTOR holds the start address of the vector table. See Vectors Table Copy from Flash to RAM section for the implementation details.

CM33 without Security extension will support only non-secure interrupts.

The default interrupt handler functions are defined to a dummy handler in the startup file. The naming convention is <interrupt_name>_IRQHandler.

Driver Usage

Initialization

Interrupt numbers are defined in a device-specific header file, such as cy8c68237bz_ble.h, and are consistent with interrupt handlers defined in the vector table.

To configure an interrupt, call Cy_SysInt_Init(). Populate the configuration structure (cy_stc_sysint_t) and pass it as a parameter along with the ISR address. This initializes the interrupt and instructs the CPU to jump to the specified ISR vector upon a valid trigger. For CM0+ core, the configuration structure (cy_stc_sysint_t) must specify the device interrupt source (cm0pSrc) that feeds into the CM0+ NVIC mux (intrSrc).

For CM4/CM33 core, system interrupt source ‘n’ is connected to the corresponding IRQn. Deep-sleep capable interrupts are allocated to Deep Sleep capable IRQn channels.

For CM0+ core, deep Sleep wakeup-capability is determined by the CPUSS_CM0_DPSLP_IRQ_NR parameter, where the first N number of muxes (NvicMux0 … NvicMuxN-1) have the capability to trigger Deep Sleep interrupts. A Deep Sleep capable interrupt source must be connected to one of these muxes to be able to trigger in Deep Sleep. Refer to the IRQn_Type definition in the device header.

1. For CPUSS_ver1 the CM0+ core supports up to 32 interrupt channels (IRQn 0-31). To allow all device interrupts to be routable to the NVIC of this core, there is a 240:1 multiplexer at each of the 32 NVIC channels.

2. For CPUSS_ver2 the CM0+ core supports up to 8 hardware interrupt channels (IRQn 0-7) and software-only interrupt channels (IRQn 8-15). The device has up to 1023 interrupts that can be connected to any of the hardware interrupt channels. In this structure, multiple interrupt sources can be connected simultaneously to one NVIC channel. The application must then query the interrupt source on the channel and service the active interrupt(s). The priority of these interrupts is determined by the interrupt number as defined in the cy_en_intr_t enum, where the lower number denotes higher priority over the higher number.

Enable

After initializing an interrupt, use the CMSIS Core NVIC_EnableIRQ() function to enable it. Given an initialization structure named config, the function should be called as follows:

NVIC_EnableIRQ(config.intrSrc)


Writing an interrupt service routine

Servicing interrupts in the Peripheral Drivers should follow a prescribed recipe to ensure all interrupts are serviced and duplicate interrupts are not received. Any peripheral-specific register that must be written to clear the source of the interrupt should be written as soon as possible in the interrupt service routine. However, note that due to buffering on the output bus to the peripherals, the write clearing of the interrupt may be delayed. After performing the normal interrupt service that should respond to the interrupting condition, the interrupt register that was initially written to clear the register should be read before returning from the interrupt service routine. This read ensures that the initial write has been flushed out to the hardware. Note, no additional processing should be performed based on the result of this read, as this read is intended only to ensure the write operation is flushed.

This final read may indicate a pending interrupt. What this means is that in the interval between when the write actually happened at the peripheral and when the read actually happened at the peripheral, an interrupting condition occurred. This is ok and a return from the interrupt is still the correct action. As soon as conditions warrant, meaning interrupts are enabled and there are no higher priority interrupts pending, the interrupt will be triggered again to service the additional condition.

Configuration Considerations

Certain CM0+ NVIC IRQn channels are reserved for system use:

 NVIC channel (IRQn_Type) Interrupt source (cy_en_intr_t) Purpose #0 (NvicMux0_IRQn) IPC Interrupt #0 (cpuss_interrupts_ipc_0_IRQn) System Calls to ROM #1 (NvicMux1_IRQn) IPC Interrupt #3 (cpuss_interrupts_ipc_3_IRQn) System IPC pipe in the default startup

note

For CPUSS_ver2, each NVIC channel can be shared between multiple interrupt sources. However it is not recommended to share the application NVIC channel with the reserved channels.