GPIO Interrupts

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 Hello,

   

This post is regarding issues arising due to multiple GPIO Interrupts ocuuring from different GPIO pins in PSoC 1. 

   

 

   

In one of the projects, there are 3 GPIO pins of PSoC 1 are used to recieve the output  of three different sensors. The interrupts of each GPIO Pin is enabled . Once the interrupt from one of the GPIO pin is received the interrupts from other pins are not getting detected. 

   

Note: The output of the sensor initially remains high. It goes low when ever there is a event  and remains there untill the event completes and then it becomes high. The interrupt  type for GPIO pin is selected as  falling edge. The events on the 3 sensors occur sequentially one after the another.

   

Any Suggestions on why this issue is arising and how to solve the issue?

0 Likes
3 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

All the GPIO ISR inputs to the interrupt controller are aggragated.

   


So best practice is to set a flag in GPIO interrupt, and exit to process in main().
Note a read of the register that records interrupts, int_clrx, will tell you which
GPIO were set.

   


I recommend reading the TRM for your part to get a handle on how PSOC interrupts
work.

   

Regards, Dana.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Since all enabled GPIOs use the same interrupt it is evident to read the states of all engaged pins and exit the ISR as soon as possible because no other GPIO-interrupt can be handled during that time.

   

Have a look here as well http://www.cypress.com/?id=4&rID=33781 it states that there exists no register to read the interrupting pin from.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I stand corrected, reading the int_clrx register only tells you if a GPIO pin

   

interrupt was posted, not what pin did it. Bob is correct, you have to read

   

pins to tell what pin interrupted. Further looks like you would have to keep

   

track of the state of ISR serving for a pin, eg. a flag/pin so that you do not

   

service a non-interrupting pin from one that is.

   

 

   

Also read the section in TRM, "Posted versus Pending Interrupts".

   

 

   

Regards, dana.

0 Likes