Solution for increased power consumption after enabling GPIO interrupt on nRF52832

[anangl]

It can be observed on the nRF52832 SoC that just enabling an edge triggered GPIO interrupt (namely, calling
gpio_pin_interrupt_configure() or gpio_pin_configure() with one of the GPIO_INT_EDGE_* flags) leads to increasing the power consumption by ~15 uA. This happens because currently (in Zephyr v2.4.0-rc1) the GPIO driver for nRF SoCs uses GPIOTE channels to detect transitions on GPIO lines and to generate the edge triggered interrupts (while the GPIO PORT event is used only for the level triggered interrupts), and the nRF52832 SoC is affected by anomaly 97.

While it is possible (although with less accuracy) to detect transitions on GPIO lines using the PORT event (and this is the workaround provided in the mentioned above anomaly description), the Zephyr GPIO driver does not provide such possibility. It would be nice to enhance the driver with such option and to provide some way for the users to select the detection method (even for nRF52832 it could be still desirable to use a GPIOTE channel for this).

Until the driver is improved, one of the following approaches can be used as a solution for the problem:

• use level triggered interrupts instead, i.e. use GPIO_INT_LEVEL_* flags to configure the interrupt (this requires also reconfiguration of the interrupt in its callback, otherwise the callback will be called again as long as the configured level is still present on the line)
• use the nrfx GPIOTE driver instead of the Zephyr GPIO one (it would need to be disabled with CONFIG_GPIO=n then)
  see the samples/boards/nrf/nrfx sample for a reference how to do it (the DPPI related part should be omitted in this context); the crucial thing is to select the PORT event as the edge detection method by applying

  		.hi_accuracy = false,
  

  in the input configuration:
  

  zephyr/samples/boards/nrf/nrfx/src/main.c

  Lines 43 to 49 in 17c4396

  	nrfx_gpiote_in_config_t const in_config = {
  	.sense = NRF_GPIOTE_POLARITY_HITOLO,
  	.pull = NRF_GPIO_PIN_PULLUP,
  	.is_watcher = false,
  	.hi_accuracy = true,
  	.skip_gpio_setup = false,
  	};

---

A related ticket in the Nordic Semiconductor's DevZone be found here.

[mhx]

FYI, I just found this issue after running into exactly the same problem with an nRF52840, and switching from edge triggered to level triggered interrupts also solved it for me. This appears to be an "Engineering A" sample (NRF_FICR->INFO.VARIANT reads AAC0, the chip is actually under a metal can on a module), and according to the errata this also suffers from anomaly 97.

[mhx]

Ah, no, AAC0 should actually be indicative of a "Revision 1" variant, which should have anomaly 97 fixed. So I'm not sure why I'm seeing this problem.

[mhx]

I've also tried a Revision 2 chip now (INFO.VARIANT == AAD0), which shows the same issue.

[trembel]

Experiencing the same issue.. When will this be fixed?

[sigurdnev]

Experiencing the same issue.. When will this be fixed?

Try setting CONFIG_GPIO_NRF_INT_EDGE_USING_SENSE=y

[anangl]

Experiencing the same issue.. When will this be fixed?

Try setting CONFIG_GPIO_NRF_INT_EDGE_USING_SENSE=y

This option is no longer available. It has been replaced by the sense-edge-mask property in "nordic,nrf-gpio" compatible nodes.

[anangl]

Addressed in #31823 and #41288.