Skip to content

EFM32 IRQ handling fix #6984

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 29, 2018
Merged

EFM32 IRQ handling fix #6984

merged 1 commit into from
May 29, 2018

Conversation

stevew817
Copy link
Contributor

Description

  • IRQ handling got updated previously to a non-functional state when both callbacks were registered (it'd fire a fall callback for both rise and fall events). With this update, that faulty behaviour is corrected. Due to delays between the detection of the edge and the handling of the interrupt (and the fact that information about which edge you received on the pin is not stored anywhere), there is no way to be absolutely sure which edge got triggered on the pin. Therefore, we make a best-guess effort by looking at the pin state at the time of IRQ handling, and fire a callback as if that was the end state of the event. This will usually work out fine, except in cases were the signal is toggling faster than the IRQ handler's response time. In that case, a user won't get both callbacks (as expected for a pulse), but only the last event.
  • Stripped some dead code.

This supersedes PR #6976 to avoid reverting back to code we know is faulty (does not detect short pulses). @DBS06

Pull request type

[X] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

* IRQ handling got updated previously to a non-functional state when both callbacks were registered (it'd fire a fall callback for both rise and fall events). With this update, that faulty behaviour is corrected. Due to delays between the detection of the edge and the handling of the interrupt (and the fact that information about which edge you received on the pin is not stored anywhere), there is no way to be absolutely sure which edge got triggered on the pin. Therefore, we make a best-guess effort by looking at the pin state at the time of IRQ handling, and fire a callback as if that was the end state of the event. This will usually work out fine, except in cases were the signal is toggling faster than the IRQ handler's response time. In that case, a user won't get both callbacks (as expected for a pulse), but only the last event.
* Stripped some dead code.
@DBS06
Copy link
Contributor

DBS06 commented May 23, 2018

Nice done!

@amq
Copy link
Contributor

amq commented May 24, 2018

My issue also remains solved, while both rise and fall work correctly.

@stevew817
Copy link
Contributor Author

Thanks for the rapid feedback @amq !

@0xc0170
Copy link
Contributor

0xc0170 commented May 26, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented May 26, 2018

Build : SUCCESS

Build number : 2163
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/6984/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented May 26, 2018

@mbed-ci
Copy link

mbed-ci commented May 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants