10 Replies Latest reply on Feb 18, 2013 12:02 AM by userc_40792

    Pins Interruption Problem

              It seems when once interruption is occured, interruption be never stop. I was set ISR_ClearPending() at end of ISR routine. Nevertheless, it's not affected. Was I forget important things for Interrupt process ? Please let me know. I was change parameters for interrupt on pin some able to sets. I attached the table and archive. Please see PDF in the archive and help. Regards PSoC73   
        • 1. Re: Pins Interruption Problem

          These might help -










          There is an example project in the lab book - http://www.cypress.com/?docID=33243




          And this - http://www.eetkorea.com/STATIC/PDF/201104/EEKOL_2011APR05_EMS_AN_01.pdf?SOURCES=DOWNLOAD




          Regards, Dana.

          • 2. Re: Pins Interruption Problem
                    Thank you Dana-san. I checked up documents. Beside that, I have make a more simple design to test this issue. So on, I found a more deep problem, HaHa. NOW: check on API level; TODO: check aroud ISR register level; It comes later... Happy PSoC?   
            • 3. Re: Pins Interruption Problem
                      ★Today's trying☆ [Phenomenon] Once interrupt is accepted, It's never stop; 1) Before interrupt and after the ISR_ClearPending, SETPEND and CLRPEND flag are ZERO always; 2) Even if set CLRPEND flag, it is not affected; 3) One interruption was ended, next interrupt rise after 10us; [Consideration] 1) Have to check by another Port,Pins; 2) Have to check up errata; 3) Have to check ES status of the chip; 4) Consulted at MyCase Happy PSoC?   
              • 4. Re: Pins Interruption Problem
                        Please look at this. ISR wave form   
                • 5. Re: Pins Interruption Problem

                  PSoCs are out in the market for several years and are frequently used by us deveopers. So when you start with deveoping PSoC projects and discover that something does not behave as you expect, it will be most likely that you mis-interpreted some information in the datasheet.


                  I admit that interrupts, especially in PSoC1, are not just easy, but we all have managed to overcome its pitfalls. Without your porject (nicely collected in an archive by PSoC Creator as you did before) we only have the choice to guess what your problem might be.


                  Some hints:


                  I was told seriously not to connect interrupts directly to mechanical switches. Reason is that bouncing may lead to unpredictable results, so use such constructs on own risk.


                  There is a better way to introduce an interrupt routine than to inject it code into a generated file: there is the Isr_StartEx() function and the CY_ISR() macros, have a look into the "Sytem Reference Guide" under Creator's help.


                  I question your list of "No Interrupt" firing. When set to rising edge and with a pull-up internally, what should happen?


                  You remove the "pending" interrrupt within your ISR, but you cannot remove the cause (pressed button) of the interrupt, so it will re-occur immediately. (Rocky Horror Picture Show: "I remove the cause..... and not the symptom")


                  Never (ever) put delays into an interrupt service routine. You did that indirectly by calling some LCD-Functions wich use delays to perform their task.




                  I would suggest:


                  Use a simple service routine that just sets a global flag which you check in your main-loop and react on when set.


                  Put some thought into the scenario when a switch is pressed for several seconds


                  Sme for a switch bouncing several (50-100) ms.




                  My best experiences I got was with a different progam-structure:


                  An interrupt from a timer (about 10 ms) checks for changes on the input - pins and sets a flag if there.


                  When not time - critical the handling can be done within the isr: Count number of similar switch readings and when a treshold is met (100-200ms) assume a switch to be pressed (or released).


                  Thus de-bouncing is done and there is a choice to act accordingly to longer switch-presses.





                  • 6. Re: Pins Interruption Problem
                            Hi Bob-san, I didn't translate your message yet. However, I have a good news. IT IS WORKING WELL! Where have I been? Anyway inform this later soon. very just sorry. Happy Happy PSoC!!   
                    • 7. Re: Pins Interruption Problem
                              I don’t care about it is about what works in any principle. If the results I expected it is OK, I don't care about or have little bug, even if the detour. Anyway, I focused on the "Find Examples" in the Start Page. And download the "GlitchFilterExsample", Adapted to my board with a minor change. It is works without any problem. then so why, What 's different, It will let you know later on also in the summary. Thank you...   
                      • 8. Re: Pins Interruption Problem
                                For now and then, I was upload the project that worked. The summary will comes tomorrow. Happy weekend and PSoC!   
                        • 9. Re: Pins Interruption Problem
                                  At first, I thought using the interrupt at the Pins for reduce interrupt resources. One Interrupt for multi Pins. For this way, NEED TO CLEAR interrupt on the Pins, I lost that. Check the datasheet of Pins, It's clearly described. // uint8 Pin_ClearInterrupt(void); // So, I had refine the design, That is here. Happy Weekend and PSoC!   
                          • 10. Re: Pins Interruption Problem
                                    PS: The way of "GlitchFilterExsample" is different, It's does not use interrupt on Pins. ISR module directly connect to Pin's output, It's can select only rise edge. To choice other edge or LEVEL interrupt, needs logic circuit. Thank you.