Increased power consumption when using GPIOTE on nrf52840

[SebastianA]

We see an increased power consumption at around 26uA when enabling GPIOTE IN events in our application with a NRF52840_xxAA_REV1 chip.

We use nRF5_SDK_15.2.0_9412b96 and the following code:

    // reg is NRF_P1, pin is 13
    reg->PIN_CNF[pin] &= ~(GPIO_PIN_CNF_DIR_Msk | GPIO_PIN_CNF_INPUT_Msk);
    reg->PIN_CNF[pin] |=
        (GPIO_PIN_CNF_DIR_Input << GPIO_PIN_CNF_DIR_Pos)
        | (GPIO_PIN_CNF_INPUT_Connect << GPIO_PIN_CNF_INPUT_Pos);

    reg->PIN_CNF[pin] &= ~GPIO_PIN_CNF_PULL_Msk;
    reg->PIN_CNF[pin] |= GPIO_PIN_CNF_PULL_Pulldown << GPIO_PIN_CNF_PULL_Pos;

    // slot is 0, portpin is 0x0100 + 13
    nrf_gpiote_te_default(slot);

    nrf_gpiote_event_configure(slot, portpin, NRF_GPIOTE_POLARITY_LOTOHI);

    NRF_GPIOTE->EVENTS_IN[slot] = 0;
    nrf_gpiote_event_enable(slot);
    nrf_gpiote_int_enable(1 << slot);


With this code our application use around 32uA. After removing the call to nrf_gpiote_event_enable, it uses around 5uA. Looking at the graph, I see that it is the baseline that is increased.

During the measurement we don't trigger the pin and the interrupt isn't called.

I've also tried the same thing on port P0.11 with the same result.

Is this an expected power increase?

[Vidar Berg]

Hello,

Yes, this is an expected power increase. For low power operation, you may consider using GPIOTE PORT events instead.

Here is typ. sleep current with IN vs PORT events from the PS (link):

ION_RAMON_GPIOTE	System ON, full 256 kB RAM retention, wake on GPIOTE input (event mode)					17.37		µA
ION_RAMON_GPIOTEPORT	System ON, full 256 kB RAM retention, wake on GPIOTE PORT event					2.36		µA

And an explanation of the difference between PORT and IN events from the GPIOTE driver documentation:

• Using a dedicated IN_EVENT: When using a dedicated IN_EVENT, one pin is assigned to an event. Only a limited number of pins can be sensed this way because there is a limited number of TASK/EVENT channels. When an IN_EVENT is enabled, it requests the high frequency clock. Therefore, this method is not suitable for scenarios where the system sleeps for a long period of time, expecting to be waken up by a pin level change. This method supports detection of toggling, low-to-high, and high-to-low transition.
• Using a PORT event: A PORT event is a single event that is triggered whenever the value of any of the input pins that have sensing enabled changes. Pins can be configured to sense low-to-high or high-to-low transition. Toggle sensing is emulated in the driver by changing the sense configuration whenever a PORT event for a given pin is detected. Using a PORT event requires only a low frequency clock. Therefore, this method is suitable for scenarios where the application expects to be inactive for a long period of time, waiting for a pin level change. The event can be shared by multiple pins; therefore it should be used for sensing slowly changing signals only.