nordic: reduce sleep current by using SENSE feature for PinAlarm when possible

[Sola85]

This PR decreases the power consumption of sleep modes with active pin interrupts by ~10x by using the SENSE feature, when possible.
"Normal" GPIOTE interrupts increase sleep current consumption by ~20µA, but using SENSE (aka PORT events) instead can reduce this to ~2µA.

This behaviour is documented as an Erratum here and discussed for Zephyr here (both for nrf52832, but it's also present in nrf52840 and also mentioned in the datasheet, Chapter "5.2.1.1 Sleep").

The documentation of nrfx_gpiote_in_init says that only 1 pin can be used for SENSE at one time, but by my own testing, 2 sense pins also work and it only breaks when trying to use 3 pins for SENSE. Hence when 3 or more PinAlarms are set, we stick to the previous behaviour.

I have tested and confirmed that the following still works after this change (using a makerdiary_nrf52840_mdk_usb_dongle and a ssci_isp1807_dev_board):

• Wake from deep sleep using 1 or 2 PinAlarms (with all combinations of high and low alarms)
• Wake from light sleep using all above PinAlarm combinations
• Wake from fake deep sleep using all above PinAlarm combinations
• correct value of alarm.wake_alarm.pin in all of the above cases.
• for 3 or more PinAlarms, the behaviour is unchanged by this PR.

But I would encourage that someone else verifies this before merging, should there be interest in this PR.

[tannewt]

Thanks for the optimization!

[mrdalgaard]

@Sola85
Have you done any tests on what the reduced accuracy of using SENSE instead of GPIOTE is? (or have you found any documentation that states it)
I'm using light sleep with pin alarms to detect events in the ~30ms range, so just wondering if I will have reduced accuracy with this change.
Otherwise awesome with more powersavings on an already very low power chip.

[Sola85]

@mrdalgaard I currently don't have the ability to do any tests (apart from simple current consumption measurements) myself. Regarding documentation, I have only found Table 5.3.8.3 "Device startup times" in the datasheet. This does not differentiate between GPIOTE and PORT events and only mentions general HW events (which might mean that there is no difference?).

In fact, the datasheet does not mention the word "accuracy" when it comes to interrupts and wake events, this only seems to appear in the nrfx SDK. (So maybe the name hi_accuracy is a misnomer?)
But if you do find any further information on this or do tests yourself, feel free to let me know!

Should there be any adverse effects for your application from this change, you can always enable "dummy" PinAlarms on 2 unused pins as a workaround to revert to the old behaviour.

[mrdalgaard]

I guess the only thing i've been able to find is the following
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Fhardware_driver_gpiote.html

High accuracy: An independent GPIOTE event is used to detect changes on the pin. If a pin is configured to be controlled in this mode, a high frequency clock is required.
Low accuracy/low power: A PORT event senses level changes on the pin. One PORT event can be used for multiple pins. Therefore, it is not that accurate and cannot be used to track high-speed pin changes. On the other hand, if a pin is configured in this mode, the system can turn off the high frequency clock when sleeping

So how i read this, we may possibly miss an interrupt from a second pin on two close events, as the event from that would be bundled with the first.
I don't know if this can cause an issue with the pin that is returned in alarm.wake_alarm, but as for waking up the cpu, i guess we don't care if its one or another.