PORT interrupts get stuck

[Ben_g]

Hi,

I have three Pins which are used as Port event interrupt source.(low-accuracy)

In some cases If I generate some interrupts (maybe 2 every second but random on at least two of the pins) something happens and then no interrpt handler is called any more. 

nrfx_gpiote_irq_handler which is the default handler is called until this error happens. Then there are no further calls.. The main loop still is running and can log to RTT Viewer. I wasn't able to get this error while debugging with Keil uVision. 

I have also seen, that  additional traffic on SPI can produce this faster. 

If I try to enable the interrupt again I got INVALID_STATE from nrfx_gpiote_in_init ( because  pin_in_use_by_gpiote is true) (Code below)

I also tried to ignore this and re-enable the interrupt anyway but that didn't work. 

I read on the DevZone and manual, that if the pin is pulled during handler routine it may get lost or something. But I did not understand, that this means all following interrupts are lost too.

My Softdevice/SDK is 15.3 

Any Ideas how to get around this? 

	nrfx_gpiote_in_config_t gpiote_in_config;
	memset(&gpiote_in_config, 0, sizeof(gpiote_in_config));
	gpiote_in_config.hi_accuracy = false;
	gpiote_in_config.is_watcher = false;
	gpiote_in_config.pull = NRF_GPIO_PIN_PULLDOWN;
	gpiote_in_config.sense = NRF_GPIOTE_POLARITY_LOTOHI;

	err_code = nrfx_gpiote_in_init(LIS2DH_INT2, &gpiote_in_config,
	        lis2dh_INT2_gpiote_evt_handler_shake);
	APP_ERROR_CHECK(err_code);
	nrfx_gpiote_in_event_enable(LIS2DH_INT2, true);

[Ben_g]

Further Info:
I now build some pin read stuff once a second for the interrupt pin. The read shows that the pin is really changing if I trigger the sensor to announce. The sensor is working correctly I guess. Sadly I have no measurement equipment to attach to this board.

Although in the end I'm pretty sure the stuck happens in the PORT event stuff. Is there a way to brute force a rebirth of this, maybe by clearing a register? I had been logging some of the NRF_GPIOTE registers but they' don't change at all after configuration. And just calling the init-routines again fails due to the checks like I wrote in the last post. 
Is it recomended to throw away the SDK-Code and do it with my own code? I'm a bit scared, that some internal softdevice-/SDK-magic may get confused by this.

EDIT: Also interesting is: If the hardware is in that stuck state. I can fully re-enable everything with triggering a NFC interrupt. I just need to read the NFC data with my android phone and it works again. The NFC interrupt handler is hidden in the softdevice afaik. I can only register a callback. 

[Sigurd]

Just to confirm, if you set 

gpiote_in_config.hi_accuracy = true;

Then it works as expected?

[Ben_g]

That's my experience. I can't say 100% sure, because I can not recreate the state with a well defined sequence. But I was not able to get to the stuck state with hi accuracy setting set to true ever. If this gives a hint to solve this, I can happily try to harden this statement?! 

Sadly hi-accuracy uses so much more current, that I'm not able to use it becuase of the small battery.

EDIT: confirmed. If I set only one of the interrupts to hi-accuracy, this wil trigger all the time as it should. While the other two get stuck after some triggering. 
If I set all three to hi-accuracy it works fine. But then it also uses in average 360uA instead of 50uA.

[Sigurd]

Hi,

In SDK v17(or more precisely in nrfx v1.8.2), we have this improvement mentioned in the release notes:

* Improved the GPIOTE driver robustness by setting the LATCH functionality to be used by default.

https://github.com/NordicSemiconductor/nrfx/blob/nrfx-1.x/master/CHANGELOG.md#changed-2

If you want to stay on SDK v15, you could try to backport this change/improvement, and see if it solves your issue.

https://github.com/NordicSemiconductor/nrfx/blob/v1.8.6/drivers/src/nrfx_gpiote.c

PS: 

Ben_g said:

But then it also uses in average 360uA instead of 50uA.

This actually sounds like this errata that is present on nRF52832: https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_89.html

 

[Ben_g]

Hi,

thank you very much. I'm out of office until Monday. But I'll take a look.