2 Replies Latest reply on May 29, 2018 3:13 PM by brte_297846

    I'm a little bit confused about AN60024 section 6.1.




      If I implement the debouncer circuit in Figure 13 of AN60024 the results I get at runtime are not what I expect (PSoC 5LP). My code is basic as it just receives the interrupt, reads the status register into a volatile variable, and then the main for loop just detects a non-zero status variable, displays the binary value to an LCD, and clears the variable. I would expect when I press the button the output would be 0b01 and when I release the button the output would be 0b10. Instead when I press the button I get an 0b01 and when I release the button I get an 0b11. What is even stranger is when I run the code through the dubugger it seems to behave as what I expect.


      Further digging I now see why it is behaving the way it is. The debouncer has a 50 Hz clock and when a button is pressed or released a 20 ms. pulse is generated on the appropriate outputs of the debouncer. The status register quickly reads in that pulse because it has a 24 MHz clock input and 'sticks' it to the appropriate register bin. When the interrupt code is executed the status register is read and cleared, but because the 20 ms. pulse is still in a high state (20 ms. is an eternity), the 24 MHz clock cycle just re-reads in that high value and keeps it in the register basically resetting what was cleared in the interrupt routine.


      My workaround was to make the status registers transparent and it works as planned.


      Has anyone else experienced this? Am I missing something here? I find it odd how AN60024 has been around for a while, yet I could find no mention of this behavior in the development community.


      Thanks and regards

        • 1. Re: I'm a little bit confused about AN60024 section 6.1.

          I would use the ISR attached to the Status Register instead of the Debouner. Then it will fire on input signals changing status only.


          • 2. Re: I'm a little bit confused about AN60024 section 6.1.

            I thought of that, but then you would get an interrupt, read the status register which would clear the register, exit the interrupt, the next rising edge of the bus clock would again alter the status register and you would get another interrupt - so on and so on until the debounce signal went low.


            One other thought would be to leave it as Figure 13 in AN60024 with the status register sticky bits and when you get the interrupt you read the status register (basically clearing the register) - wait a small amount of time for the next bus clock rising edge, and then read the status register again which should give you the actual state of the inputs to the status register. Seems a but clunky to me, but I guess it beats sampling the switches in code.


            Again, it is odd to me that this has not come up earlier - so I was thinking I must be doing something incorrect.