SysInt (System Interrupt)

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

Modules
	Macros
	Global variables
	Functions
	Data Structures
	Enumerated Types

Detailed Description

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

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 __VECTOR_TABLE 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. For example:

void ioss_interrupts_gpio_0_IRQHandler(void)
{
    ...
}

And can be used like this:

    #define INTERRUPT_SOURCE_GPIO  ioss_interrupts_gpio_0_IRQn

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

    /* Prototype of ISR function for gpio interrupt 0, defined as a weak function in startup_psoc4_*.s */
    void ioss_interrupts_gpio_0_IRQHandler(void);

    cy_stc_sysint_t intrCfg =
    {
        /*.intrSrc =*/ INTERRUPT_SOURCE_GPIO, /* Interrupt source is GPIO port 0 interrupt */
        /*.intrPriority =*/ 3UL                     /* Interrupt priority is 3 */
    };

    /* Initialize the interrupt with vector at Interrupt_Handler_Port0() */
    Cy_SysInt_Init(&intrCfg, (cy_israddress)NULL);

    /* 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.

Driver Usage

Initialization

Interrupt numbers are defined in a device-specific header file, such as cy8c4146azi_s433.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. All the supported interrupts are listed in IRQn_Type. The priority of these interrupts is determined by the interrupt number (index in the IRQn_Type enumeration).

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

Below is an example of typical interrupt configuration:

    #define INTERRUPT_SOURCE_GPIO  ioss_interrupts_gpio_0_IRQn

    /* Scenario: Vector table is relocated to RAM in __RAM_VECTOR_TABLE[] */

    /* Prototype of ISR function for port interrupt 0 */
    void Interrupt_Handler_Port0 (void);

    cy_stc_sysint_t intrCfg =
    {
        /*.intrSrc =*/ INTERRUPT_SOURCE_GPIO, /* Interrupt source is GPIO port 0 interrupt */
        /*.intrPriority =*/ 3UL                     /* Interrupt priority is 3 */
    };

    /* Initialize the interrupt with vector at Interrupt_Handler_Port0() */
    Cy_SysInt_Init(&intrCfg, &Interrupt_Handler_Port0);

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

More Information

Refer to the technical reference manual (TRM) and the device datasheet.

Changelog

Version	Changes	Reason for Change
1.10.2	Updated undefined values in the code snippets.	Documentation enhancement.
1.10.1	Update the paths to the code snippets.	PDL structure update.
	Minor documentation updates. Code snippets were updated.	Documentation enhancement.
1.10	Moved vector table declaration to the system header file.
	Fixed MISRA violations.	MISRA compliance.
	Minor documentation updates.	Documentation enhancement.
1.0	Initial version