InterruptIn always pulled up on nRF52_DK when BLE is initialized

[HITMAnsOFT]

Description

• Type: Bug
• Priority: Major

---

Bug

Target
nRF52_DK (tested both on a custom board and on a Sparkfun nRF52832 breakout)

Toolchain:
GCC_ARM

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

mbed-cli version:
1.1.1

mbed-os sha:
98ba8ac Merge pull request #4974 from ARMmbed/release-candidate

DAPLink version:

Expected behavior
After calling mode(PinMode::PullDown) on an InterruptIn, if the pin is floating, the voltage measured on the pin should be around 0V.
Actual behavior
If BLE is initialized, the voltage on an InterruptIn pin is always pulled up (reads 3.3V on a multimeter). DigitalIn works correctly.
Steps to reproduce
Build and run the following code:

#include "ble/BLE.h"
#include <mbed.h>

InterruptIn button(p24); // Any dangling pin here

int main()
{
    BLE &ble = BLE::Instance();
    ble.init();
    button.mode(PinMode::PullDown);
    return 0;
}

Measure the voltage on p24 with a multimeter.

[HITMAnsOFT]

I've made the following workaround in targets/TARGET_NORDIC/TARGET_NRF5/gpio_api.c, in function gpio_apply_config:

diff --git a/targets/TARGET_NORDIC/TARGET_NRF5/gpio_api.c b/targets/TARGET_NORDIC/TARGET_NRF5/gpio_api.c
index ec73afa6a..d5f9bd909 100644
--- a/targets/TARGET_NORDIC/TARGET_NRF5/gpio_api.c
+++ b/targets/TARGET_NORDIC/TARGET_NRF5/gpio_api.c
@@ -130,8 +130,18 @@ static void gpio_apply_config(uint8_t pin)
             cfg.hi_accuracy = false;
             cfg.is_watcher = false;
             cfg.sense = NRF_GPIOTE_POLARITY_TOGGLE;
+            switch(m_gpio_cfg[pin].pull) {
+                case PullUp:
+                    cfg.pull = NRF_GPIO_PIN_PULLUP;
+                    break;
+                case PullDown:
+                    cfg.pull = NRF_GPIO_PIN_PULLDOWN;                                                                                                                                       
+                    break;                                                                                                                                                                  
+                default:                                                                                                                                                                    
+                    cfg.pull = NRF_GPIO_PIN_NOPULL;                                                                                                                                         
+                    break;
+            }
             if (m_gpio_cfg[pin].used_as_irq) {
-                cfg.pull = NRF_GPIO_PIN_PULLUP;
                 nrf_drv_gpiote_in_init(pin, &cfg, gpiote_irq_handler);
                 if ((m_gpio_irq_enabled & ((gpio_mask_t)1 << pin))
                     && (m_gpio_cfg[pin].irq_rise || m_gpio_cfg[pin].irq_fall))
@@ -140,17 +150,6 @@ static void gpio_apply_config(uint8_t pin)
                 }
             }
             else {
-                switch(m_gpio_cfg[pin].pull) {
-                    case PullUp:
-                        cfg.pull = NRF_GPIO_PIN_PULLUP;
-                    break;
-                    case PullDown:
-                        cfg.pull = NRF_GPIO_PIN_PULLDOWN;
-                    break;
-                    default:
-                        cfg.pull = NRF_GPIO_PIN_NOPULL;
-                    break;
-                }
                 nrf_drv_gpiote_in_init(pin, &cfg, NULL);
             }
         }

This works for my application.
I have an external debounce circuit that has high impedance, so the internal pull-up was not allowing the pin to reach low level. In order for it to work, I need to disable all internal pull-ups.
For some reason, for all pins that are configured as IRQs the Pull-up was hard-coded. Anyone knowledgeable on the matter, please advise.

EDIT: improved the fix by pulling the switch statement out of the if statement instead of duplicating it.

[0xc0170]

cc @pan- @nvlsianpu @anangl

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-184

[0xc0170]

This one fixes this issue #7220