5 Replies Latest reply on Jan 4, 2020 1:30 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.

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

              I just got back to this project after a long hiatus working on another project... I thought it would be a good idea to kind of round out this post with what I finally found out.


              The switches that I am using on the prototype board are quite old (found in the junk box), and as it turns out they are very bouncy. Putting an oscilloscope on the switch and trigging off of the first transition I am seeing bounce activity in excess of 300 milliseconds - crazy long. They are conductive rubber push button switches, and most likely the rubber has either deteriorated or the contact surface has gotten contaminated.


              My interim fix for the prototype was to put in an RC network and connecting that to a 74HC14 Hex Inverting Schmitt Trigger. I set the time constant so that after 200 milliseconds the voltage will hit the lowest specified voltage of the high input transition of the Schmitt Trigger. The 200 to 300 millisecond delay incurred is well within typical user expected button press/release response time. I know that the PSoC inputs have hysteresis, but the hysteresis window is fairly narrow and not as well defined as it is in the 74HC14.


              Of course the ultimate solution is to use a much better and newer switch, but this is a good lesson on how bad a switch can get over time with a solution that can be used to compensate. Now on to ordering new switches

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


                There is a custom component for button events processing with heavy denouncing, which may be helpful here

                ButtonSw32: button switch debouncer component


                1 of 1 people found this helpful
                • 5. Re: I'm a little bit confused about AN60024 section 6.1.

                  Thank you for this. I appreciate the links in the documentation giving the background information. Software versus hardware based solutions, the age old argument. Back in the day when I made a living doing engineering work a hardware based solution was generally given more weight in the decision process as the microcontrollers had very limited speed and memory to work with (i.e. Intel 8748 and Motorola 68HC05 type of devices) I will most definitely give this a good looking at before I commit to the PCB layout and fabrication.