Unable to disable GPIOTE for nRF Connect SDK 2.6.1

[Christopher]

Hi, 

Recently I upgraded to nRF Connect SDK 2.6.1 and I was required to enable the GPIOTE in order to build properly. Doing this has significantly increased (nearly doubled) the total current consumption at runtime. How can I disable this peripheral now? I am unable to do so now using the overlay file.

Old: 

&gpiote {
    status = "disabled";
};

New:

&gpiote {
    status = "okay";
};

Thank you,

[Simonr]

Hi Christopher

Susheel asked me if I could take over this case, and indeed it seems like something is drawing a lot of power on your external board. In my opinion 199µA on the older SDK is also a bit high if your application is just doing GPIOTE, so I'm guessing your application does something else as well. 

First off, to try and achieve the same power consumption on NCS v2.6.1, can you go through the migration guides for NCS v2.5.0 and v2.6.0 to make sure you've made all the necessary changes to your project in order to make it running as it should on v2.6.1?

Next, if you use Visual Studio Code and the nRF Connect extensions for development, you can use the nRF DeviceTree visual editor to see what pins and peripherals exactly are enabled in your project and check for any discrepancies between the NCS 2.4.2 and 2.6.1 versions of your project.

Best regards,

Simon

[Christopher]

This is all on a custom board. There are many other peripherals running, which is why you see 199uA. I am now trying to upgrade the SDK to the 3.0.2 and having the same issues.

I am running the software and have GPIOTE1 disabled in the device tree, but I am still able to get P1.00 to interrupt on the application core. 

I understand the GPIOTE is required for interrupts, but it is unclear why it works in the older SDK when I disabled them in the device tree. It worked and resulted in a lower power draw. 

My overall goal is to get the lowest possible power draw while using interrupts. How can I go about this? I tried the suggestion above, but the sense-edge-mask did not make much of a difference.

[Edvin]

Hello,

What happens when you try to disable the gpiote? What worked in the older SDKs? Disabling GPIOTE while still receiving interrupts from other peripherals?

What was the current consumption in the old application, and what is the current consumption in the new one? Apart from enabling GPIOTE, are there any other changes to the application?

Do you have an application showing that it doesn't work in the new SDKs?

Best regards,

Edvin

[Christopher]

This is all rather strange to me too. In the older SDK everything works just fine and all GPIOs interrupt correctly as the should. When I build the code, I reviewed the DTS files and observed I have GPIOTE disabled in all child images (e.g. mcuboot, b0, b0n, application, network). However, I am unable to disable the GPIOTEs in my child images and thus I am assuming that is the reason why I have about a ~200uA increase in current consumption.

I need to take a step back and just do a simple test with a single GPIO input trigger. I can then compare the two SDKs to ensure it isn't another peripheral running. 

I should also point out I am using the nRF5340DK board files.

Thank you,

[Christopher]

Would you be able to show me an example of how to configure a GPIOTE interrupt which will consume the least amount of current on a nRF53? I cannot seem to get it work properly. 

Thank you,

[Edvin]

Hello Christopher,

This ticket is getting quite old, so I am not sure what your current status is. What do you observe when setting up the GPIOTE interrupt?

Does it work?

What is your current consumption?

What is your expected current consumption?

Best regards,

Edvin

[Christopher]

So, after investigating a little further. It appears like it was a new configuration required for using the NFC pins on the nRF53. I needed to add the following to my .dts file. 

&uicr {

nfct-pins-as-gpios;

};

My assumption was this was always triggering a read of my ADC which was causing some extra current draw.

Thank you for the assistance. We can close this now.