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

Correctly enable / disable InterruptIn Edges detection #4676

Merged
merged 4 commits into from Jul 17, 2017

Conversation

Projects
None yet
4 participants
@LMESTM
Contributor

LMESTM commented Jun 30, 2017

Description

When disabling GPIO irq, also the falling / rising edge settings need
to be reset (EXTI_RTSR and EXTI_FTSR registers).

See #2959:
If not reset, the same EXTI line can be later enabled again with a wrong
Rising / Falling configuration. This was especially seen and reported in
ci-test tests-api-interruptin on NUCLEO_F446RE target where DIO2=PA_10 and
DIO6=PB_10 were successively tested: as they are sharing the same EXTI_LINE
(EXTI_10), this resulted in calling the irq_handler with wrong
IRQ_FALL/IRQ_RAISE parameter and donothing being called in loop

Also after correctly disabling, another commit handles the save restore part.

Finally en error is added in case of spurious interrupt to make it easily detectable.

Status

READY

Tests results

NUCLEO_F446RE ci-test-shield passed ok
+-----------------------+---------------+-----------------------------+--------+--------------------+-------------+
| target | platform_name | test suite | result | elapsed_time (sec) | copy_method |
+-----------------------+---------------+-----------------------------+--------+--------------------+-------------+
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-analogin | OK | 12.3 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-analogout | OK | 11.27 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-businout | OK | 27.7 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-digitalio | OK | 12.94 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-i2c | OK | 13.87 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-interruptin | OK | 12.72 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-pwm | OK | 176.18 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-spi | OK | 15.53 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-analogin | OK | 15.12 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-analogout | OK | 10.99 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-digitalio | OK | 13.72 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-i2c | OK | 11.36 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-pwm | OK | 11.86 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-pwmout | OK | 11.19 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-assumptions-spi | OK | 11.81 | shell |
+-----------------------+---------------+-----------------------------+--------+--------------------+-------------+
mbedgt: test suite results: 15 OK

All families Interrupt-in tests passed
+-----------------------+---------------+-----------------------+--------+--------------------+-------------+
| target | platform_name | test suite | result | elapsed_time (sec) | copy_method |
+-----------------------+---------------+-----------------------+--------+--------------------+-------------+
| NUCLEO_F091RC-ARM | NUCLEO_F091RC | tests-api-interruptin | OK | 57.33 | shell |
| NUCLEO_F091RC-GCC_ARM | NUCLEO_F091RC | tests-api-interruptin | OK | 58.05 | shell |
| NUCLEO_F103RB-ARM | NUCLEO_F103RB | tests-api-interruptin | OK | 58.64 | shell |
| NUCLEO_F103RB-GCC_ARM | NUCLEO_F103RB | tests-api-interruptin | OK | 60.54 | shell |
| NUCLEO_F207ZG-ARM | NUCLEO_F207ZG | tests-api-interruptin | OK | 54.88 | shell |
| NUCLEO_F207ZG-GCC_ARM | NUCLEO_F207ZG | tests-api-interruptin | OK | 57.05 | shell |
| NUCLEO_F303ZE-ARM | NUCLEO_F303ZE | tests-api-interruptin | OK | 57.77 | shell |
| NUCLEO_F303ZE-GCC_ARM | NUCLEO_F303ZE | tests-api-interruptin | OK | 57.77 | shell |
| NUCLEO_F446RE-ARM | NUCLEO_F446RE | tests-api-interruptin | OK | 56.6 | shell |
| NUCLEO_F446RE-GCC_ARM | NUCLEO_F446RE | tests-api-interruptin | OK | 57.0 | shell |
| NUCLEO_F767ZI-ARM | NUCLEO_F767ZI | tests-api-interruptin | OK | 56.52 | shell |
| NUCLEO_F767ZI-GCC_ARM | NUCLEO_F767ZI | tests-api-interruptin | OK | 56.04 | shell |
| NUCLEO_L073RZ-ARM | NUCLEO_L073RZ | tests-api-interruptin | OK | 59.84 | shell |
| NUCLEO_L073RZ-GCC_ARM | NUCLEO_L073RZ | tests-api-interruptin | OK | 60.43 | shell |
| NUCLEO_L152RE-ARM | NUCLEO_L152RE | tests-api-interruptin | OK | 57.28 | shell |
| NUCLEO_L152RE-GCC_ARM | NUCLEO_L152RE | tests-api-interruptin | OK | 58.14 | shell |
| NUCLEO_L476RG-ARM | NUCLEO_L476RG | tests-api-interruptin | OK | 57.24 | shell |
| NUCLEO_L476RG-GCC_ARM | NUCLEO_L476RG | tests-api-interruptin | OK | 57.45 | shell |
+-----------------------+---------------+-----------------------+--------+--------------------+-------------+

LMESTM added some commits Jun 30, 2017

STM32 Fuly disable GPIO irq settings
When disabling GPIO irq, also the falling / rising edge settings need
to be reset (EXTI_RTSR and EXTI_FTSR registers).

If not reset, the same EXTI line can be later enabled again with a wrong
Rising / Falling configuration. This was especially seen and reported in
ci-test tests-api-interruptin on NUCLEO_F446RE target where DIO2=PA_10 and
DIO6=PB_10 were successively tested: as they are sharing the same EXTI_LINE
(EXTI_10), this resulted in calling the irq_handler with wrong
IRQ_FALL/IRQ_RAISE parameter and donothing being called in loop.
STM32: Raise error in case of spurious interrupt
In case we've run through the entire GPIOs loop, withouth finding a
matching interrupt, we're in the case of a spurious interrupt, let's
raise an error to track it down.
STM32: Store and restore rising falling config of gpio_irq
Now that rising / falling edge detection is disabled in the
gpio_irq_disable function, we also need to restore it when gpio_irq_enable
gets called.
@0xc0170

LGTM, just one line seems misaligned?

LL_EXTI_EnableRisingTrig_0_31(1 << STM_PIN(obj->pin));
}
if (obj->event & IRQ_FALL) {
LL_EXTI_EnableFallingTrig_0_31(1 << STM_PIN(obj->pin));

This comment has been minimized.

@0xc0170

0xc0170 Jul 4, 2017

Member

misaligned

This comment has been minimized.

@LMESTM

LMESTM Jul 7, 2017

Contributor

I had forgotten that one ... done now !

@0xc0170 0xc0170 added needs: work and removed needs: review labels Jul 4, 2017

@0xc0170 0xc0170 added needs: CI and removed needs: work labels Jul 10, 2017

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jul 10, 2017

/morph test

@mbed-bot

This comment has been minimized.

mbed-bot commented Jul 11, 2017

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 760

Example Build failed!

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jul 11, 2017

I noticed this failure for the second time today, IAR for one nucleo target, mash minimal throws an error, traceback does not say much, assuming this is assembly file, wrong CPU or ? @LMESTM Are you able to reproduce this? Please look at the CI output

@0xc0170

This comment has been minimized.

Member

0xc0170 commented Jul 13, 2017

/morph test

@mbed-bot

This comment has been minimized.

mbed-bot commented Jul 13, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 805

All builds and test passed!

@0xc0170 0xc0170 added ready for merge and removed needs: CI labels Jul 14, 2017

@theotherjimmy theotherjimmy merged commit 185b723 into ARMmbed:master Jul 17, 2017

4 checks passed

Cam-CI uvisor Build & Test Success
Details
ci/morph-test Job has completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment