nrfx GPIOTE conflict with Zephyr GPIO API

[Stephan Walter]

We are using the Zephyr IIS2DLPC driver to talk to that sensor from an nRF5340. This driver uses the Zephyr GPIO API to configure interrupts, which is implemented in drivers/gpio/gpio_nrfx.c. That module manages GPIOTE channels and uses hal/nordic/nrfx/hal/nrf_gpiote.h for register access.

We would also like to use GPIOTE for other purposes, for example as an input to a timer in counter mode, where no interrupts should be generated.

We wanted to use the nrfx_gpiote driver for this, but this has its own GPIOTE channel management that conflicts with gpio_nrfx.c

Is our understanding correct? And what is the best way to avoid these conflicts?

[Håkon Alseth]

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.

 

Is our understanding correct? And what is the best way to avoid these conflicts?

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

[Stephan Walter]

Thanks you Hakon for the speedy reply. You wrote:

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

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?

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?

[Håkon Alseth]

Hi,

 

Stephan Walter said:

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?

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).

Stephan Walter said:

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?

 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