SysInt (System Interrupt)

General 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

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 group_system_config_device_vector_table section for the implementation details.

Note

Because the IAR compiler expects the vector table to be defined as __vector_table, when compiling with IAR, both the __ns_vector_table and __s_vector_table symbols are aliased to instead be defined as __vector_table. The generated .map files per project will contain no references to __ns_vector_table or __s_vector_table, but will instead contain references to __vector_table. The project containing the .map file will still indicate which vector table (secure or non-secure) is being used in that project. i.e. proj_cm33_s.map's __vector_table would refer to the secure vector table.

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.

CM55

CM55 is without Security extension and will support only non-secure interrupts. It is similar to CM33 non-secure part. Additionally CM55 core has support to block EWIC (External Wakeup Interrupt Controller). EWIC is a peripheral to the processor and it can be a source of wakeup in the system. EWIC block is disabled by default and needs to be enabled in order for the DS wakeup source to work.

 
    /* Scenario: Vector table is relocated to RAM in __ramVectors[] */
 
    /* Prototype of ISR function for port interrupt 0. For CY_IP_M7CPUSS port 21 is configured */
    void Interrupt_Handler_Port0 (void);
 
    /* Initialize the interrupt with vector at Interrupt_Handler_Port0() */
    Cy_SysInt_Init(&intrCfg, &Interrupt_Handler_Port0);
 
    /* Enable the interrupt */
#if (CY_IP_M7CPUSS)
    NVIC_EnableIRQ((IRQn_Type) NvicMux3_IRQn);
#else
    NVIC_EnableIRQ(intrCfg.intrSrc);
#endif
 

Driver Usage

Initialization

Interrupt numbers are defined in a device-specific header file, such as cy_device_headers.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 CM33/CM55 core, system interrupt source 'n' is connected to the corresponding IRQn. Deep-sleep capable interrupts are allocated to Deep Sleep capable IRQn channels.

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.

More Information

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

API Reference
	Macros
	Functions
	Data Structures
	Enumerated Types