Proper configuration of GPIO IRQ on nRF52

RE: Proper configuration of GPIO IRQ on nRF52

ovrebekk — Fri, 08 Mar 2024 09:54:31 GMT

Glad I could help Daniel, the best of luck with your project 🙂

RE: Proper configuration of GPIO IRQ on nRF52

dnil-daniel — Thu, 07 Mar 2024 20:52:12 GMT

Thanks for providing a clear and comprehensive answer to this question, appreciated!

RE: Proper configuration of GPIO IRQ on nRF52

ovrebekk — Tue, 05 Mar 2024 10:23:51 GMT

Hi Daniel

Håkon is currently unavailable, and I will help you out in the mean time.

Essentially the problem is the errata you point to, yes. By default the GPIO driver will use GPIOTE IN events for handling interrupts (callbacks), and because of this errata issue the sleep current in this case will not be in the single digit microamp range anymore. The solution is to add the sense-edge-mask property, which will make the GPIO driver use the GPIOTE PORT event rather than dedicated GPIOTE IN channels.

You can read more about the PORT event in the documentation here. Essentially this event can be enabled on any pin and is not limited by the number of GPIOTE channels, but whenever the event is triggered the GPIO driver needs to check the state of the GPIO registers to verify which of the enabled pins actually changed (since you no longer get a dedicated event for each pin). Using the PORT event bypasses the GPIOTE IN channel issue and means you will get significantly lower current consumption in sleep.

[quote user="dnil-daniel"]What I'd like to know is what is the current (as of nRF Connect SDK 2.5.x) supported and recommended way to setup edge triggered IRQs on external pins on the nRF52 SoC using the Zephyr API? [/quote]

You can look at standard Zephyr samples, such as the basic button sample, and add the sense-edge-mask property.

[quote user=""]Maybe related question, on this nRF52832 SoC it doesn't seem possible to enable PM via "CONFIG_PM=y" since the SoC does not set the "HAS_PM" flag. Is PM and/or PM_DEVICE supported on the nRF SoCs, can drivers add hooks here for additional power savings?[/quote]

PM is not supported in the nRF devices for the simple reason that the power management system in most nRF devices is quite simple: Whenever you are not doing anything (ie the idle thread is running) the system will automatically put you in system on idle sleep mode, and this mode will not prevent any other peripherals in the system from running, so there is no need to use the PM module to set up complex policies or other rules to handle power management.

The critical aspect of this system though is that the sleep currents depend on whichever peripherals are running, so while the system is simple in use it does put some responsibility on the application developer to not leave peripherals running if they are not used.

The PM_DEVICE and PM_DEVICE_RUNTIME are supported by some of the peripheral drivers and can be used to put peripherals in sleep when they are not needed, which is critical to achieve low average currents when peripherals are in use.

PM_DEVICE allows you to disable device drivers in a standardized way, and can as an example be used to disable the UART when it is not used, since keeping the UART driver running will lead to very high sleep currents.

PM_DEVICE_RUNTIME is used by some drivers to handle power management in an automatic way, and if you use I2C device for instance it is highly recommended to enable this. Then the I2C peripheral will be automatically put to sleep whenever no I2C transactions are running.

Best regards
Torbjørn

RE: Proper configuration of GPIO IRQ on nRF52

dnil-daniel — Mon, 26 Feb 2024 15:33:33 GMT

Current is measured using an Agilent 34401A DMM on both the custom hardware and on the nRF52 DK eval board, I get the expected current after enabling the "sense-edge-mask" property to the issue is not with the actual measurement. Custom hardware also gives expected current consumption after enabling "sense-edge-mask", but in this case I need to enable it on more pins since the custom hardware has a more complex setup with several external sensors configured to send IRQs to nrf52.

What I'm trying to understand is the correct setup on the Zephyr API-level for nRF52 and external IRQs. This bug seems relevant:

https://github.com/zephyrproject-rtos/zephyr/issues/28499

Seems that at the bottom of this is this anomaly:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev2%2FERR%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_97.html

Zephyr GPIO API seems to be using GPIOTE channels which are affected by anomaly 97. "sense-edge-mask" appears to use GPIO sense instead of GPIOTE, is that correct? Somewhere here is also GPIO PORT events mentioned, how are those related? Many hours googling and testing various old and new bits of information here...

What I'd like to know is what is the current (as of nRF Connect SDK 2.5.x) supported and recommended way to setup edge triggered IRQs on external pins on the nRF52 SoC using the Zephyr API?

Please also comment on my questions regaring CONFIG_PM?

RE: Proper configuration of GPIO IRQ on nRF52

helsing — Mon, 26 Feb 2024 14:32:32 GMT

Hi Daniel,

[quote user=""]this works but results in high current consumption of the SoC.[/quote]

How do you measure the current?

[quote user=""]on the real target hardware[/quote]

Has anyone at Nordic reviewed your custom hardware? We can review the Nordic related part of the design as a free service.