nrfx GPIOTE conflict with Zephyr GPIO API

RE: nrfx GPIOTE conflict with Zephyr GPIO API

Stephan Walter — Thu, 11 Feb 2021 07:14:07 GMT

This seems to be fixed now in this commit: https://github.com/nrfconnect/sdk-zephyr/commit/a86ac1f8c2a48e32ed824f0f5ea49d45ceaa345f

RE: nrfx GPIOTE conflict with Zephyr GPIO API

Håkon Alseth — Fri, 04 Dec 2020 09:27:09 GMT

Hi,

[quote user="sw"]

I have come across edge vs. level triggering before and I'm confused about how exactly they behave and when to choose which. On top of that there is the port event and the sense mechanism. Compared to other MCU families the nRF chips seem very complicated in this regard.

When should one use the sense mechanism?

[/quote]

The simple answer is:

For accuracy; use GPIOTE IN. Where accuracy is not required, use PORT.

GPIOTE IN will require a bit more current in sleep than a GPIO configured with SENSE (thus; it generates a GPIOTE PORT event).

[quote user="sw"]We have to patch the IIS2DLPC driver anyway, so we might change it to not use GPIOTE. If I understand you correctly this would mean that nrfx_gpiote can exclusively manage GPIOTE. But what would the consequence be in terms of latency, power consumption etc?[/quote]

GPIOTE IN will add some current to your base current, in the area of 30 uA on nRF9160 (which is very similar to nRF5340), but a high speed NRF_TIMERx peripheral will use the peripheral clock tree, thus keep that running in sleep, giving you this sleep current:

https://infocenter.nordicsemi.com/topic/ps_nrf5340/chapters/current_consumption/doc/current_consumption.html?cp=3_0_0_3_3_0_15#unique_474202684

The above numbers are based on capture/compare mode, but for counter mode; this should not rely on the clock tree, thus you should have a much lower current consumption.

I have an old sample, made around the release of ncs v1.1.0 I believe, which uses DPPI/TIMER (cc mode; the fw times a GPIOTE IN pulse width):

https://github.com/Rallare/fw-nrfconnect-nrf/blob/nrf9160_samples/samples/nrf9160/nrfx_timed_signal/src/main.c

As of newer ncs versions: The applications Kconfig, where NRFX components are selected, is not required, nor is this config line:

https://github.com/Rallare/fw-nrfconnect-nrf/blob/nrf9160_samples/samples/nrf9160/nrfx_timed_signal/prj.conf#L11

Hope this helps clear the DPPI vs. PPI scenario a bit.

Kind regards,

Håkon

RE: nrfx GPIOTE conflict with Zephyr GPIO API

Stephan Walter — Thu, 03 Dec 2020 16:30:49 GMT

Thanks you Hakon for the speedy reply. You wrote:

Interrupt enabled pins, without edge-triggering, will be configured using the GPIOTE PORT event.

When should one use the sense mechanism?

We have to patch the IIS2DLPC driver anyway, so we might change it to not use GPIOTE. If I understand you correctly this would mean that nrfx_gpiote can exclusively manage GPIOTE. But what would the consequence be in terms of latency, power consumption etc?

RE: nrfx GPIOTE conflict with Zephyr GPIO API

Håkon Alseth — Thu, 03 Dec 2020 13:08:28 GMT

Hi,

Note that the zephyr gpio driver will only use a dedicated GPIOTE IN channel if the gpio is setup with edge-triggering.

Interrupt enabled pins, without edge-triggering, will be configured using the GPIOTE PORT event.

[quote user=""]Is our understanding correct? And what is the best way to avoid these conflicts?[/quote]

Your understanding is correct. Those two drivers don't play well together, and this was unfortunately never the intention either. The normal scenario is to either use zephyr drivers for things, or use nrfx. Since zephyr's gpio API doesn't expose the use for GPIOTE IN events and tasks, I fully understand your situation.

Since you cannot get a hold of the gpio_nrfx.c::gpiote_alloc_mask (its static, and not returned anywhere), there's no current good way of determining this w/o editing, other than reading the algorithm for allocation (starting from 0 and increments), and making sure your integration and the zephyr driver does not overlap. This isn't very bullet proof, so be sure to comment your implementation thoroughly..

An additional test-vector: I would recommend that you also check the NRF_GPIOTE->CONFIG[n] register against the reset value, just to see if someone has tried to access it:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/gpiote.html?cp=2_0_0_5_4_3_12#register.CONFIG

Fortunately, you do not require interrupts for your second algorithm. If you would have used interrupts; you would have had to either patch the zephyr driver, or chosen to only use nrfx.

Kind regards,

Håkon