NRF52 interrupts already activated by fall/rise call

[ChiSaw]

Description of defect

In InterruptIn::fall(..) and InterruptIn::rise(..) calling gpio_irq_set in target https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5x/gpio_api.c#L221 , the interrupts get activated per default. This results in direct ISR calls on hardware if the interrupt input pin is floating during boot up for example. Per default interrupts shouldn't be activated after hooking up an ISR with fall or rise, right? Only after explicitly calling InterruptIn::enable_irq().

Target(s) affected by this defect ?

NRF52832

Toolchain(s) (name and version) displaying this defect ?

• (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 7.12.1.20170417-git

What version of Mbed-os are you using (tag or sha) ?

mbed-os-5.9.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.8.1

How is this defect reproduced ?

• empty mbed project

• main.cpp

   #include "mbed.h"
  
  volatile uint8_t count = 0;
  void handler() {
      count++;
  }
  
   void main() {
       InterruptIn interrupt(p0);
       interrupt.fall(callback(&handler));
       while(1);
   }
  

and then toggling p0 on hw e.g. calls handler() for me

[0xc0170]

As the example in the InterruptIn header file shows, fall/raise method enabled interrupts - only required to have a callback. Activated by default.

enable/disable irq were added later, to be able to disable/re-enable only interrupts for specific input (in most cases it is actually the entire port).

[drahnr]

From an API POV this goes against a common pattern - one wants to attach a callback once, and the enable disable based on some business logic.
Also the API documentation says nothing about the irq being activated https://os.mbed.com/docs/v5.9/mbed-os-api-doxy/classmbed_1_1_interrupt_in.html#a774eed83bdbd9a95ea530b2eee9b7754

[0xc0170]

From an API POV this goes against a common pattern - one wants to attach a callback once, and the enable disable based on some business logic.

This is how attach functionality is designed in the drivers (you can review attach methods, the object does not have enable/disable these callbacks). Either valid callback or NULL (former enables, latter disables).

Also the API documentation says nothing about the irq being activated

Please review @ARMmbed/mbed-os-hal

[ciarmcom]

@ChiSaw thank you for raising this issue.Please take a look at the following comments:

Could you add some more detail to the description? A good description should be at least 25 words.
What target(s) are you using?
What toolchain(s) are you using?
What version of Mbed OS are you using (tag or sha)?
It would help if you could also specify the versions of any tools you are using?
How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[drahnr]

@ciarmcom Not sure what else there is to be added here, all the requested information is already present in the initial comment.

[adbridge]

@drahnr We've updated our automation to use a new issue template, I will fix the requirements .