nRF52 DK does not run GPIOTE interrupt handler after some time with SoftDevice 132 present

[bvuong87]

Hi All,

I'm having a problem with my application which involves regularly sampling I2C slave data and sending it over Bluetooth. The I2C slave generates an active high interrupt when new data is available, which signals my application to read the data as well as write to some registers to clear the interrupt to prepare it for the next sampling interval. This active high interrupt is mapped to a GPIOTE interrupt which looks for the low to high transition and calls the event handler I just described

This seems to work well at least initially, but after some time (which varies anywhere from 30 seconds - 10 mins) my NRF52 stops servicing the interrupt. In other words, the slave fires an interrupt, but afterwards the NRF52 does not issue the I2C start condition to begin reading the new data and writing to the required registers to clear the new data interrupt.

The part that is puzzling to me, is that the time which elapses before the "timeout" happens is not very consistent. At times, the application will run for 10+ minutes with no problems, while at others this condition will occur in under a minute.

I've attached a trace of my I2C data lines, as well the interrupt on Channel 2 (not SCL as noted in the screen) to better illustrate my problem.

I'm using the nrf52 DK PC10036, with SD 1.0.0.3 alpha, with Software Packs nrf_drivers version 3.1.0 and nrf_libraries version 4.0.0.2.

Any thoughts or recommendations would be appreciated!

Thanks

[RK]

PCA10036 has lots of anomalies, including this one

infocenter.nordicsemi.com/index.jsp

which affects GPIO interrupts among other things. Have you tried the workaround for that issue?

[bvuong87]

RK - Thanks for the quick reply! I did come across issue 73 previously, and tried the workaround unsuccesfully, but am not completely certain I implemented it properly.

I placed the workaround code into both the start of my main() as well as inside of the main() function's infinite loop

if (*(volatile uint32_t *)0x4006EC00 == 0) 
{ *(volatile uint32_t *)0x4006EC00 = 0x9375; } 
*(volatile unit32_t *) 0x4006EC14 = 0xC0;

[bvuong87]

Seems I may have found the cause of my problem! Thanks to RK's who helped point me into looking at missing GPIOTE events.

While configuring my sensor input interrupt pin, GPIOTE sense from LOTOHI was set to use Low Accuracy.. i.e:

nrf_drv_gpiote_in_config_t gpioConfig = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);

Switching this over to a high accuracy event seems to have resolved this problem through a few hours of testing this morning.

nrf_drv_gpiote_in_config_t gpioConfig = GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);

The literature regarding the GPIOTE driver notes that low accuracy/power mode is not suitable for high speed pin changes which may be applicable to my sensor interrupt which fires an active high interrupt with a pulse width of 16us.

Hope this helps somebody who encounters something similar