nrf_drv_gpiote_init() causes unwanted hard fault from other pin input

[John]

Hello,

I have been trying to resolve an issue for a few days now.  Here is what I'm trying to do.  

1. initialize gpiote and tie a pin to an interrupt handler

static void peripherial_init(void)
{
	ret_code_t err_code;
	err_code = nrf_drv_gpiote_init();
	APP_ERROR_CHECK(err_code);

	nrf_drv_gpiote_in_config_t vl_int_config = GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
	err_code = nrf_drv_gpiote_in_init(VL_INT, &vl_int_config, vl_int_pin_handler);
  APP_ERROR_CHECK(err_code);

	nrf_drv_gpiote_in_event_enable(VL_INT, true);	
}

2. initialize a gpio as an input and read it from an application timer every 50ms.

    //Digital Inputs
		nrf_gpio_cfg(BTN_MSTR,
								 NRF_GPIO_PIN_DIR_INPUT,
								 NRF_GPIO_PIN_INPUT_CONNECT,
								 NRF_GPIO_PIN_PULLUP,
								 NRF_GPIO_PIN_S0S1,
								 NRF_GPIO_PIN_SENSE_LOW);

The GPIOTE pin (P0.06) is different from the gpio input pin (P0.13).  The gpio input pin is connected to a button.  I use the button to turn the device on and off.  This works great if I don't call peripherial_init().  If I call peripherial_init() and then push the button.  The processor hangs.  If I hold the button down, the processor hangs until my watchdog times out, then the device resets.

The GPIOTE interrupt works as expected.

I am using SDK 17.1 with softdevice S132_nRF52_7.2.0 nRF52832 with RC 32.768kHz (no external 32.768kHz Oscillator)

Thanks,

John  

[Kenneth]

Hello,

I suggest to look at pin change interrupt example project if you havent' already, to verify that work as expected:
\examples\peripheral\pin_change_int

If you find that you have a problem with a pin in specific (e.g. P0.06 fails, but 0.13 works), then I would likely check if it can be a conflict of two or more peripherals trying to use the same pin. For instance P0.06 is frequently used for UART (e.g. logging).

Best regards,
Kenneth

[John]

Kenneth,

If I do not run peripherial_init() which calls nrf_drv_gpiote_init(), the button GPIO when pressed or held does NOT hard stop the processor.  It works as expected. 

I made sure there are no other initialization routines that mess with any of the GPIO.  

I did follow the pin_change_int example and implemented it into my firmware and it works as expected, but it changes how the other gpio (button) responds in the firmware application.

If you would like, I can zip up my application and you can take a look if you don't have any other ideas as to what is causing the issue.

Thanks,

John

[Kenneth]

Sounds to me that maybe the gpiote interrupt is executing in a loop continously here, have you done any check that is the case (e.g. check nrfx_gpiote_irq_handler() in nrfx_gpiote.c is running in a loop)?

Any difference if you use GPIOTE_CONFIG_IN_SENSE_HITOLO(false);?

I think part of the problem here is that nrf_drv_gpiote_in_init() also configure an input with sense (in event if .hi_accuracy=true, and port event if hi_accuracy=false), so when you manually have called nrf_gpio_cfg() you are adding a port event that the gpiote driver is not aware of. Better to always use nrf_drv_gpiote_in_init() if you want the system to wakeup on in or port events.

Kenneth