nRESET Pin floating in Deep Sleep which is causing wake up unintentionally

[Aswin Matthew]

Hello All,

I am having a trouble with the nReset Pin during Deep Sleep. The issue is that the board is waking up from Deep Sleep due to floating nReset Pin. I am using a nrf52480.

Before going to a Deep Sleep I am making this nReset Pin to the following configuration:-

    // Disable The GPIO needed for N_RESET_PIN
    nrf_gpio_cfg( N_RESET_PIN,
                         NRF_GPIO_PIN_DIR_INPUT,
                         NRF_GPIO_PIN_INPUT_CONNECT,
                         NRF_GPIO_PIN_PULLUP,
                         NRF_GPIO_PIN_S0S1,
                         NRF_GPIO_PIN_NOSENSE);

However when in deep sleep I manually checked that the nReset pin is in floating or Pull Up mode using a multimeter. Connected a multimeter (supposed to be very high impedance) to between Vdd and nRESET. Measured 0V as expected.

Then connected multimeter between gnd and nRESET. Measured 2.2V, however the sensor started to advertise.

As per this observation it is seen that the Pin configuration is going to NO_PULL from PULLUP while calling a Deep Sleep Function sd_power_system_off().

Why does this happen ?. Is there a work around for this ?.

Thanks,
Aswin :)

[Jared]

Hi

 

Before going to a Deep Sleep I am making this nReset Pin to the following configuration:-

    // Disable The GPIO needed for N_RESET_PIN
    nrf_gpio_cfg( N_RESET_PIN,
                         NRF_GPIO_PIN_DIR_INPUT,
                         NRF_GPIO_PIN_INPUT_CONNECT,
                         NRF_GPIO_PIN_PULLUP,
                         NRF_GPIO_PIN_S0S1,
                         NRF_GPIO_PIN_NOSENSE);

 This is not quite how you enable PIN RESET on nRESET pin. 

See the system_nRF52840.c file for a example on this:

    /* Configure GPIO pads as pPin Reset pin if Pin Reset capabilities desired. If CONFIG_GPIO_AS_PINRESET is not
      defined, pin reset will not be available. One GPIO (see Product Specification to see which one) will then be
      reserved for PinReset and not available as normal GPIO. */
    #if defined (CONFIG_GPIO_AS_PINRESET)
        if (((NRF_UICR->PSELRESET[0] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos)) ||
            ((NRF_UICR->PSELRESET[1] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos))){
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[0] = 18;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_UICR->PSELRESET[1] = 18;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
            while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
            NVIC_SystemReset();
        }
    #endif

[Aswin Matthew]

Hello,

Thanks for your reply. I have already used the above code to enable PIN RESET on nRESET pin. However since the nRESET pin doesnt have an external PULL UP I want to  configure the GPIO Pin to an internal PULL UP. Hence the configuration is done before a deep sleep.

I have printed the pin config as well as the PSELRESET register values before going to deep sleep and is as follows.

reg->PIN_CNF[18]    = 12
NRF_UICR->PSELRESET[0]    = 18
NRF_UICR->PSELRESET[1]    = 18

#Please note the debugger is not used in the actual case.

[Jared]

Hi,

The pullup is automatically enabled when you set it as a reset pin.

regards

Jared

[Aswin Matthew]

But its found that the PIN is floating. The below are the observations:-

Connected a multimeter (supposed to be very high impedance) to between Vdd and nRESET. Measured 0V as expected.

Then connected multimeter between gnd and nRESET. Measured 2.2V, however the sensor started to advertise.

Repeated the test a few times, also with a 800k resistor, the same happens.

What may be the reason its set to Floating ?

[Jared]

Well, yes the pin shouldn't float. Are you using a custom board? If you are, then the next step would be to flash your application on a development kit and see if the issue is reproducible. You can upload your design files if the issue is not reproducible on the development kit.