Wake up from GPIO pin

[mmmark84]

Hi,

I am struggling with a low power consumption solution for waking the NRF52832 with our product which is using a third part module.

Currently our product total power consumption is 20uA during nrf_pwr_mgmt_run() (which is fine for now, it has allot of other devices on board which take up a big portion of this 20uA).

We have several inputs connected to GPIO pins (but only one at the moment for testing). We need to be able to wake the device from nrf_pwr_mgmt_run() but we also need to know which pin caused this wake up.

The inputs we want to use are pulled to ground when activated and pulled up with the pullup inside the NRF52832 during idle.

Currently I tried the following 2 solutions, which both have issues:

void in_pin_handler(nrfx_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
	switch(pin)
	{	case 31:
			//BuzzerOK();
		break;
	}
}

void GPIO_init(void)
{   ret_code_t err_code;
    err_code = nrfx_gpiote_init();
    APP_ERROR_CHECK(err_code);		
    
    nrfx_gpiote_in_config_t in_config31 = NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true); // Set hi_accu to true to use IN_EVENT. 
    in_config31.pull = NRF_GPIO_PIN_PULLUP;
    err_code = nrfx_gpiote_in_init(31, &in_config31, in_pin_handler); // in_pin_handler = IN_EVENT
    nrfx_gpiote_in_event_enable(31, true);
}

Above works fine for waking up and knowing what pin did it, however the power consumption during nrf_pwr_mgmt_run(); is way too high when I enable the event with nrfx_gpiote_in_event_enable(). I am using a uA meter which is 100uA max and it goes off this scale.

I also tried this:

void GPIO_init(void)
{   ret_code_t err_code;
    err_code = nrfx_gpiote_init();
    APP_ERROR_CHECK(err_code);		
    
    nrf_gpio_cfg_sense_input(31, NRF_GPIO_PIN_PULLUP, NRF_GPIO_PIN_SENSE_LOW);
}

Which seem to work fine for waking it up and with no power issue during nrf_pwr_mgmt_run()  (20uA again), but I have no way of knowing what IO caused the wakeup (or at least I cannot find it in the documentation).

I am having trouble finding a good solution for this.

[Turbo J]

Look at the errata sheet: The GpioTE IN events pull a lot more current.

Workaround: Use the "port" event (sense bits in PIN_CNF[x] registers), and the NRF_GPIO -> LATCH register to detect which I/O triggered the event.

[bjorn-spockeli]

as Turbo J has pointed out, using the IN event to detect a pin change will lead to an increase in the current consumption. This is because the IN event requires the HF clock to be running, i.e. adding about 250uA. The PORT event on the other hand does not require the HF clock to be running and is therefore better suited for low power applications. 

You should only have to change NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(true) to NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(false) in the first code snippet and you should see the current consumption drop significantly. 

Best regards

Bjørn

[mmmark84]

Thank you! I tried port mode and that seems to work fine with the button. I hope its usable for our other devices which will generate a shorter pulse.

The event handler seems to work fine as well now with port mode (however I also get an event when going low->high...).

[bjorn-spockeli]

Ok, let me know if you run into any issues with shorter pulses. Hmm, is the sense configuration set to NRF_GPIOTE_POLARITY_HITOLO and not NRF_GPIOTE_POLARITY_TOGGLE?   I guess you can add a check for which type of event that generated the interrupt? 

[mmmark84]

Seems fine for an other pin I just tested, maybe its due to debugging and using a button which does allot of bouncing when pressing it or something.