reducing current consumption of nrf5340 GPIO interrupts configured for edge triggering

[sshenoy105]

I have a few GPIOs configured as interrupt pins.. most are edge triggered GPIO_INT_EDGE_FALLING or GPIO_INT_EDGE_RISING (won't work otherwise so, i cant go for level triggered at this time)..Only button is GPIO_INT_LEVEL_INACTIVE..  Looks like in 1.9.1 we need to add an entry in overlay to take care of masking for sense-edge and i did..

&gpio0 {
status = "okay";
sense-edge-mask = < 0xffffffff >;
};

&gpio1 {
status = "okay";
sense-edge-mask = < 0xffffffff >;
};

Will making interrupts edge triggered add lot 10s of extra uA like it is mentioned in some older tickets ? is there a way around that I am missing ?

Older tickets talked about using CONFIG_GPIO_NRF_INT_EDGE_USING_SENSE but as we all know that macro doesn't seem to exist anymore.. some ticket mentioned setting hi_accuracy parameter to false for gpio config.. some ticket mentioned setting low latency to 0  (haven't found a zephyr api to do that yet( but I am using the interrupt set up as follows and can't find any other  way

Is there a way to use edge triggered interrupts and not take up too much power at all ?  I have searched as much as I could but couldn't get anywhere.. I have 5 gpios configured and hence any current saved will be awesome.

[sshenoy105]

here's one example of how I set up the interrupt.. and please note that this works exactly as expected and there are no issues.. level triggering does not work and hence i can;t use it.. question is only about finding a way to use edge triggered interrupts that don;t take too much power

bool xx_nrf5340_gpio_interrupt_for_xx_setup(void) {
int ret;
xx_nrf5340_gpio_1_init();
gpio_pin_configure(gpio_1_dev, NRF53440_GPIO_PIN_FOR_xx_INTR, GPIO_INPUT);

ret = gpio_pin_interrupt_configure(gpio_1_dev, NRF53440_GPIO_PIN_FOR_xx_INTR, GPIO_INT_EDGE_FALLING);
if (ret != 0) {
printk("Error %d: failed to configure xx interrupt pin %d\n", ret, NRF53440_GPIO_PIN_FOR_xx_INTR);
return false;
}

gpio_init_callback(&xx_cb,
xx_intr_process,
BIT(NRF53440_GPIO_PIN_FOR_xx_INTR));

gpio_add_callback(gpio_1_dev, &xx_cb);
return true;
}

[Marte Myrvold]

Hi,

Several of our experts on this are out of office, but I will check internally and get back to you.

Best regards,

Marte

[Marte Myrvold]

Hi,

How much current consumption are you actually seeing, and what is the exact difference in current consumption between using sense and not? I cannot say whether the difference is to be expected or not without knowing what it actually is.

Are you using other things with high current consumption? Please try disabling logging/serial.

You can also see typical numbers for current consumption here: nRF5340 current consumption.

Best regards,

Marte

[sshenoy105]

i have seen that datasheet.. it is honestly not clear as to what should be expected when I have bunch of GPIOs configured for interrupt.. 

In any case, at least two of my peripheral interrupts create havoc if I have both edges configured.. and hence i wont be able to go with your solution .. will just have to live with the power consumption.

I had another ticket about all things power but i was told to file separate tickets for each issue going forward.. 

Thank you for your help.. you can close this ticket since there doesn't seem to be a real way to do what I wanted to do

[u9357]

If you use GPIO_INT_TRIG_BOTH | GPIO_INT_ENABLE. It will fail an assertion Only one of GPIO_INT_LOW_0, GPIO_INT_HIGH_1 can be enabled for a level interrupt

[Rait]

I'm getting the same assertion failure when assert is enabled. Is there a solution for this? 

CONFIG_ASSERT=y

gpio_pin_interrupt_configure_dt(&m_config.gpioDtSpec, GPIO_INT_ENABLE | GPIO_INT_TRIG_BOTH)

ASSERTION FAIL [((flags & (1U << 22)) == 0) || ((flags & (1U << 24)) != 0) || ((flags & ((1U << 25) | (1U << 26))) != ((1U << 25) | (1U << 26)))] @ WEST_TOPDIR/zephyr/include/zephyr/drivers/gpio.h:881
Only one of GPIO_INT_LOW_0, GPIO_INT_HIGH_1 can be enabled for a level interrupt.

[Rait]

The problem with assert still exists in the latest 2.6.0 release of the SDK. Can Nordic provide guidance on how to get this configuration working without hacks (like overriding assert macro locally)?