PCAL6524: Does the switch debouncer routine need to be satisfied before an ISR is triggered?

cancel
Showing results for 
Search instead for 
Did you mean: 

PCAL6524: Does the switch debouncer routine need to be satisfied before an ISR is triggered?

Jump to solution
238 Views
MicroFoundry
Contributor II

Greetings - when utilizing the switch debouncer feature of the PCAL65xx IO Expander, does the switch debouncer need to be fully satisfied before an interrupt will be triggered, as I assumed it is? I'm looking for positive confirmation on this as it would seem that is not the case. The product data sheet (Rev. 2 - 15 May 2019)  states in section "6.5.12 Interrupt edge registers (60h-65h)" the following: "If an entry is 01b, only a pos-going edge will cause an interrupt event, while a 10b will require a neg-going edge to cause an interrupt event. These edge interrupts events are latched, regardless of the status of the Input Latch Register (48h, 49h, 4Ah)..."

On my prototype and in my code, the ISR is a one line "Set a flag to true" for which I process in the main body loop with a simple if(ISR_FLAG){ read the 3 Interrupt Status Registers (58h-5Ah) followed by reading the 3 Input ports (00h-02h), and output via serial or oled}. With this simple code, it's not that difficult to lightly trigger a traditional push button with micro-switch and fire the ISR. But when the Loop routine executes I see there are no inputs latched at the port. It is true the Interrupt Status Register will always properly reflect which Port/Pin triggered the ISR, but it's possible to trigger the switch quick enough to where the input port does NOT reflect a latched input on the pin that triggered the ISR which leads me to my assumption the debouncer routine has not completed.

What am I missing here? My current proto PCB doesn't lend itself to hooking up a logic analyzer so I'll have to build another unit with some tiny test leads and wire the switch input to a second device from which I can deliver a known one-shot pulse and see how it all plays out on the LA. I just hope there's a definitive answer than my current speculation.

TIA,

Terry Phillips

Tags (3)
0 Kudos
1 Solution
220 Views
JozefKozon
NXP TechSupport
NXP TechSupport

Hi Terry,

please see below for an answer from an application engineer I have contacted.

DESCRIPTION

Greetings - when utilizing the switch debouncer feature of the PCAL65xx IO Expander, does the switch debouncer need to be fully satisfied before an interrupt will be triggered, as I assumed it is? I'm looking for positive confirmation on this as it would seem that is not the case. The product data sheet (Rev. 2 - 15 May 2019)  states in section "6.5.12 Interrupt edge registers (60h-65h)" the following: "If an entry is 01b, only a pos-going edge will cause an interrupt event, while a 10b will require a neg-going edge to cause an interrupt event. These edge interrupts events are latched, regardless of the status of the Input Latch Register (48h, 49h, 4Ah)...

[A] Yes, it is correct. The switch debounce condition has to be fully satisfied before an interrupt will be triggered.

"On my prototype and in my code, the ISR is a one line "Set a flag to true" for which I process in the main body loop with a simple if(ISR_FLAG){ read the 3 Interrupt Status Registers (58h-5Ah) followed by reading the 3 Input ports (00h-02h), and output via serial or oled}. With this simple code, it's not that difficult to lightly trigger a traditional push button with micro-switch and fire the ISR. But when the Loop routine executes I see there are no inputs latched at the port. It is true the Interrupt Status Register will always properly reflect which Port/Pin triggered the ISR, but it's possible to trigger the switch quick enough to where the input port does NOT reflect a latched input on the pin that triggered the ISR which leads me to my assumption the debouncer routine has not completed.What am I missing here? My current proto PCB doesn't lend itself to hooking up a logic analyzer so I'll have to build another unit with some tiny test leads and wire the switch input to a second device from which I can deliver a known one-shot pulse and see how it all plays out on the LA. I just hope there's a definitive answer than my current speculation

[A] It depends on Input latch registers settings. If “Input latch registers” are set to “0”, then input ports value is not latched (just read in current port value, rather the port value while interrupt was occurred). And if “Input latch registers” are set to “1”, then input ports value is latched while interrupt was occurred.

If customer can provide initialization code for PCAL6524, then I can review it.

 

With Best Regards,

Jozef

View solution in original post

0 Kudos
4 Replies
223 Views
MicroFoundry
Contributor II

Hi Jozef - in a nut-shell, it's a personal IoT project geared towards cloud based data collection and machine control for the arcade industry. If it's truly a necessity to know more information, I would possibly consider sharing it in a one-to-one conversation.

With regards to the issue I'm seeing, hopefully there will be some promising news. I actually changed the design once before to incorporate the PCAL6524 over competing products. The primary reason was the debouncer capability even with the additional expense of more IO than necessary and cost of an external oscillator. Unfortunately at this point it makes a PSoC 4200DS solution re-design a viable alternative.

Regardless, I'll likely be offering PCAL65xx breakout boards and Arduino library soon as I do like the devices...

Thank you,

Terry

0 Kudos
221 Views
JozefKozon
NXP TechSupport
NXP TechSupport

Hi Terry,

please see below for an answer from an application engineer I have contacted.

DESCRIPTION

Greetings - when utilizing the switch debouncer feature of the PCAL65xx IO Expander, does the switch debouncer need to be fully satisfied before an interrupt will be triggered, as I assumed it is? I'm looking for positive confirmation on this as it would seem that is not the case. The product data sheet (Rev. 2 - 15 May 2019)  states in section "6.5.12 Interrupt edge registers (60h-65h)" the following: "If an entry is 01b, only a pos-going edge will cause an interrupt event, while a 10b will require a neg-going edge to cause an interrupt event. These edge interrupts events are latched, regardless of the status of the Input Latch Register (48h, 49h, 4Ah)...

[A] Yes, it is correct. The switch debounce condition has to be fully satisfied before an interrupt will be triggered.

"On my prototype and in my code, the ISR is a one line "Set a flag to true" for which I process in the main body loop with a simple if(ISR_FLAG){ read the 3 Interrupt Status Registers (58h-5Ah) followed by reading the 3 Input ports (00h-02h), and output via serial or oled}. With this simple code, it's not that difficult to lightly trigger a traditional push button with micro-switch and fire the ISR. But when the Loop routine executes I see there are no inputs latched at the port. It is true the Interrupt Status Register will always properly reflect which Port/Pin triggered the ISR, but it's possible to trigger the switch quick enough to where the input port does NOT reflect a latched input on the pin that triggered the ISR which leads me to my assumption the debouncer routine has not completed.What am I missing here? My current proto PCB doesn't lend itself to hooking up a logic analyzer so I'll have to build another unit with some tiny test leads and wire the switch input to a second device from which I can deliver a known one-shot pulse and see how it all plays out on the LA. I just hope there's a definitive answer than my current speculation

[A] It depends on Input latch registers settings. If “Input latch registers” are set to “0”, then input ports value is not latched (just read in current port value, rather the port value while interrupt was occurred). And if “Input latch registers” are set to “1”, then input ports value is latched while interrupt was occurred.

If customer can provide initialization code for PCAL6524, then I can review it.

 

With Best Regards,

Jozef

View solution in original post

0 Kudos
200 Views
MicroFoundry
Contributor II

Jozef - thank you for validating my question. I had time to build another prototype today and set it up with leads and a PWM signal as a clock signal to the PCAL6524, making it easy to see the timing and such. And no great surprise everything worked as desired. 

So I looked at the 1st prototype to determine why it was producing such odd results. After some poking and prodding around on the PCB, I discovered the culprit. I'm embarrassed to say I grabbed a 1MHz osc by mistake. Needless to say that's a bit too fast for debouncer. Once it was replace with a 1KHz PWM signal from the MCU the original board is working as desired too. 

Silver lining: Another lesson learned and 3 other components eliminated off the schematics...

Thank you for the help and best regards,

Terry

0 Kudos
229 Views
JozefKozon
NXP TechSupport
NXP TechSupport

Hi Terry,

could you please provide the information below?

Customer: ?

End Customer: ?

End Application: ?

Country: ?

Annual Volume: ?

With Best Regards,

Jozef

0 Kudos