Cypress Perform

Home > Cypress Developer Community > Blog Posts > PSoC Sensei Blog > Introduction to Interrupts for PSoC 4 Hardware Blocks


Introduction to Interrupts for PSoC 4 Hardware Blocks
Jul 01, 2013
By Bradley Budlong
With PSoC 4, new blocks in the device handle interrupts a bit differently than before with PSoC 3 and 5LP. The main difference is the usage of the Write-One-To-Clear methodology.
 
I'll use the TCPWM as an example of how this type of interrupt is used and controlled.  The following are the APIs that are applicable to interrupts for the TCPWM:
  • void SetInterruptMode(uint32 interruptMask)
    Used to control which interrupt sources are able to generate an interrupt. There are defined values for each of the sources. For the TCPWM an interrupt can be generated based on a terminal count or based on either a compare value or a capture. This function doesn't need to be called if the interrupt sources are configured using the component customizer. This function modifies the INTR_MASK register for the block.
  • uint32 GetInterruptSourceMasked()
    This is the function that you want to call when the interrupt fires. It allows the interrupt routine to determine which interrupt source caused the interrupt. The same defined values are used to indicate which source caused the interrupt. This function returns the value of the INTR_MASKED register for the block.
  • uint32 GetInterruptSource()
    Similar to the GetInterruptSourceMasked() function except it doesn't take into account which mask bits are enabled or disabled. This function is useful when polling for the condition to occur instead of being triggered by an interrupt. This function returns the value of the INTR register for the block.
  • void ClearInterrupt(uint32 interruptMask)
    Once the condition has occured, the interrupt bit will stay set until the bit is cleared. This function is used to clear the specified bits. This is implemented by writing a one bit to the INTR register. 
  • void SetInterrupt(uint32 interruptMask)
    With this function the interrupt can be forced to occur without requiring the actual hardware condition to occur. It will cause the interrupt condition to be seen by the hardware and software in the same way as it would be if the actual hardware interrupt had occurred. This is useful to test out the operation of the interrupt code. This function writes to the INTR_SET register for the block.
To try this out I'm going to use the TCPWM configured as a PWM and configured to generate an interrupt at each terminal count. Note that in the customizer I've configured the PWM to generate an interrupt "On terminal count" so the SetInterruptMode() function doesn't need to be called.
 
 
To use the interrupt an Interrupt Service Routine (ISR) needs to be created. There are two options. Either a function can be created and tied to the interrupt using the StartEx() function from the interrupt component, or the provided interrupt routine that is provided with the interrupt component can be edited in the merge region. I recommend that you use the StartEx() implementation because it allows you to separate your code from the generated code.
 
I want to monitor when the ISR code is executing so I've created a software controlled pin (PWM_isr_active) that will be high during the execution of the interrupt.
 
Here's the first attempt at an ISR, but it is flawed:
 
 
Looking at the waveform that is generated for the PWM_isr_active signal in yellow and the PWM_out signal in blue, you can see that the interrupt is executing more rapidly than the PWM:
 
 
The problem is that the interrupt is not being cleared, so it executes as fast as it can over and over.
 
Here's a second attempt at an ISR and this one clears the interrupt source before returning from the interrupt:
 
 
The waveform now is exactly as expected.  The ISR is triggered at the terminal count and shortly after that the pin has been written to indicate that the ISR is active. Then the interrupt completes and isn't called again until the next PWM period.:
 
 
If I wanted to debug the operation of my interrupt routine I could have also just triggered the interrupt without running the PWM.  In this case however I do need to set the interrupt source since I'm not calling the PWM Start() function which sets the interrupt source based on the customizer setting:
 
 
The output from this test looks very similar, except that the PWM isn't running:
 
 
There are other variations that can also be used with this PWM example. A polled implementation could be done using GetInterruptSource(). If this function had been called instead of GetInterruptSourceMasked() then the value returned would have shown both bits set, since the compare and the terminal count happen during each PWM period and the interrupt mask is not used for this function.
See full blog


Comments:
sego wrote:
Your topic is very advanced.
I have a very simple problem with generating timer interrupt every 1 second. Synthesis simply fails.
I have a simple problem with UART. Off the shelf uart don't fit into the clock 2% variation limit, which guaranties successful
communication.  
Maybe it would be a good start up for this tutorial.
Fri Jul 19 02:56:36 AM
sego wrote:
Manual says: Don't use C functions within interrupt code as it increase latency.
I guess this is only inspiration for real application
Thu Jul 25 03:53:36 AM
bjbu wrote:
Please let me know which manual provided that guidance so that I can have it changed.  It is a good idea to keep interrupt routines low overhead, but you will be using function calls in interrupts.  Whatever doesn't need to be done in the interrupt should be done outside of the interrupt, but the interrupt example here is very reasonable.  You'll generally want to see exactly the cause of the interrupt and you'll need to clear the interrupt along with taking some action.  Generally you'll want to avoid blocking functions that consume significant time, but if you do need to execute something that takes a long amount of time, then PSoC 3 / 4 and 5LP all offer multiple levels of interrupt priority, so you can still have a lengthy interrupt at a low priority and get low latency to a high priority interrupt.  You'll need to evaluate for your system what level of interrupt response time you can afford and plan accordingly.  With PSoC you also have the advantage that many things that would have normally required CPU interaction can be done using programmable hardware and therefore the tasks with low latency response requirements are often just handled in hardware with PSoC.
Fri Jul 26 00:08:29 AM
You must be logged in to leave a comment. Login / Register
Like this item? Spread the news:  
Post this story on Digg.com Digg this   Share this on Facebook.com Facebook   Post this story on Digg.com LinkedIN   Add to Twitter Twitter  
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". CYPRESS SEMICONDUCTOR AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY CYPRESS SEMICONDUCTOR. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM CYPRESS SEMICONDUCTOR.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms and Conditions of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms and Conditions of this site. Cypress Semiconductor and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Spec No: None; Sunset Owner: DWV; Secondary Owner: JMAL; Sunset Date: 06/15/20