GPIO interrupts cause high current consumption during sleep on nrf9160 and nrf52833

[batuhanates]

I am doing power optimizations on a custom hardware that has nrf9160 and nrf52833 on it. These are connected via GPIO pins and I use two pins to send interrupts to each other.

I noticed when I turn off the interrupts, nrf9160 has around 5.5 - 7 uA sleep current and nrf52833 has around 2 uA sleep current. But when I turn on the interrupts nrf9160 has around 40 uA sleep current and nrf52833 has 10 uA sleep current. I tested on several boards and all have similar results.

So why does GPIO interrupts cause higher sleep current and how can I lower it?

I use zephyr gpio api for configuring the pins and interrupts. For turning off the interrups I just comment out the following function.

static void com_gpio_init(void)
{
    gp_gpio = device_get_binding(DT_LABEL(DT_NODELABEL(gpio0)));
    gpio_pin_configure(gp_gpio, COM_INT_OUT_PIN, GPIO_OUTPUT_INACTIVE);
    gpio_pin_configure(gp_gpio, COM_INT_IN_PIN, GPIO_INPUT | GPIO_PULL_DOWN);
    gpio_pin_interrupt_configure(gp_gpio, COM_INT_IN_PIN, GPIO_INT_EDGE_RISING);
    gpio_init_callback(&g_gpio_callback, com_gpio_callback_func, 1u << COM_INT_IN_PIN);
    gpio_add_callback(gp_gpio, &g_gpio_callback);
}

[Vidar Berg]

Hello,

Please try replace the GPIO_INT_EDGE_RISING flag with GPIO_INT_LEVEL_HIGH and see if that helps lowering the IDLE current. The difference between the two is that the latter will configure GPIOTE to use PORT events which should have little to no impact on sleep current.

Idle current - GPIOTE IN events vs. GPIOTE Port events (Sleep)

[batuhanates]

Thank you for the quick reply.

I’ve done a quick test with GPIO_INT_LEVEL_HIGH flag and it lowers the idle current as you mentioned.

But, I wonder if this could cause the interrupt to trigger multiple times and should I take extra measures against it? In the callback function all I do is give a semaphore. Also, in order to send the interrupt I set the corresponding pin to high and back to low again from the other chip.

I’ll do more tests to make sure it works as intended but I would be happy to know if there is anything I should be careful about.

[batuhanates]

While using the GPIO_INT_LEVEL_HIGH flag the interrupt is not triggered unless I put a delay between set 1 and set 0 function calls on the other side. And even when I put a delay as small as 1ns then the interrupt is triggered multiple times which causes problems for the application.

Do you have any suggestions to make sure the interrupts is triggered only once when using the level flags? I've  tried disabling the interrupt at the beginning of callback and reenabling at the end but it is still triggered multiple times.

static void com_gpio_callback_func(const struct device *p_port, struct gpio_callback *p_cb, gpio_port_pins_t pins)
{
    gpio_pin_interrupt_configure(gp_gpio, COM_INT_IN_PIN, GPIO_INT_DISABLE);
    k_sem_give(&g_com_sem);
    gpio_pin_interrupt_configure(gp_gpio, COM_INT_IN_PIN, GPIO_INT_LEVEL_HIGH);
}

[Vidar Berg]

Does it help if you increase the pulse width to lets say 100 useconds? I can't think of any good reason for why you would get multiple events when using GPIOTE PORT , but not when using edge triggering with GPIOTE IN.

[batuhanates]

It doesn’t help. I tried 1us, 10us, 100us, and 1ms. All of them caused interrupt to trigger multiple times. I think it keeps triggering while the signal is high when using level flags.

[Vidar Berg]

Did you not get these duplicate events when you use EDGE triggering earlier? That's the part that confuses me the most. I would expect edge triggering to produce more events if anything.

Assume you have common ground between the chips, but do they also share the same IO voltage? Also, do you have an oscilloscope that you can probe the signal with?