nrfx GPIOTE conflict with Zephyr GPIO API

Question

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 · Accepted Answer

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

nrfx GPIOTE conflict with Zephyr GPIO API

Top Replies