EFM32: GPIO Irq not working as expected since mbed-os 5.8.1

[MikeDK]

Description

• Type: Bug
• Related issue: #6205
• Priority: Major

---

Bug

Target
observed on an EFM32PG12 (probably all EFM32)

Toolchain:
GCC_ARM

Toolchain version:
arm-none-eabi-gcc (15:5.4.1+svn241155-1) 5.4.1 20160919

mbed-cli version:
1.2.0

mbed-os sha:
b033a6e

Expected behavior
I wrote a class for debouncing a button. It uses an InterruptIn object, where I register callback functions for both InterruptIn::rise() and InterruptIn::fall().
When button is pressed, the fall callback gets called, and when button is released, the rise callback will be called.

Actual behavior
Only the fall callback function is called for both rising and falling edge since mbed-os release 5.8.1. It was working with 5.8.0 and before.

I found out that commit 2a3d6d4 from #6315 is causing the problem.
If I revert this commit, everything is working again.

Steps to reproduce
On an EFM32PG12, create an InterruptIn object on pin BUTTON1 or BUTTON2, and register both rise and fall callback with different functions. Push the button -> fall callback function gets called ... Release the button again -> fall callback function gets called again instead of the rise callback.

[0xc0170]

@ARMmbed/team-silabs Please review

[stevew817]

Looks like a classic bounce problem coupled with there being an 'else if' instead of a second 'if'. Will fix the mess-up with the 'else if', but am tempted to say that debouncing becomes the user's problem.

[MikeDK]

Of course the debouncing has to be handled by the user ... that's why I wrote a class for it, using a timeout for the debouncing.
Its just that the commit which causes the problem in fact changed the interface ... somewhere in the text regarding the original problem is stated that the user has to check the state of the pin now ... so why should then still be the possibility to register seperate rise and fall handlers?

And what is also interesting, is that this issue did not pop up on any continuous integration test, and the error has been present in two mbed os releases without anyone noticing it ;)

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-64

[amq]

@0xc0170 this has been fixed in #6984