Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PORT interrupts get stuck

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

Parents
  • 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. 

  • Just to confirm, if you set 

    gpiote_in_config.hi_accuracy = true;

    Then it works as expected?

Reply Children
No Data
Related