Rare occurrences of interrupt from Accelerometer not waking system from sd_app_evt_wait()

[koniho]

We have an application running on a custom board with the following configuration:

nrf52832

SDK v12.3

Softdevice S132 v3.1.0 and S332 v2.0.0 (different variants of PCB)

During sleep operation, the nrf52832 is configured to have two wake sources with GPIOTE, one is from a user activated button, another is an interrupt from an accelerometer (BMA253). Both GPIOTE are configured as active low `SENSE_HI_TO_LO` in low accuracy mode. The accelerometer is configured to output a pulse of 12.5 ms when activity is detected.

The GPIOTE configuration is shown below:

    nrf_drv_gpiote_in_config_t irq_pin_config =
        GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);

    irq_pin_config.pull = NRF_GPIO_PIN_PULLUP;

    err_code = nrf_drv_gpiote_in_init(ACTVITY_INT_PIN,
        &irq_pin_config, acc_irq_handler);

    APP_ERROR_CHECK(err_code);

    nrf_drv_gpiote_in_event_enable(ACTVITY_INT_PIN, true);

Normally, the devices all wake as expected from accelerometer detected activity. We have observed rare occurrences where a device appears to not be waking from accelerometer activity. We have confirmed the no-wake condition both by non-responsiveness to wireless controls and also by not being detected via BLE advertising. Once a user presses the button, the device appears to wake as expected and continue normal operation. From this point on - the accelerometer appears to wake the system correctly.

From the Product Specification (http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpiote.html?cp=2_1_0_20_1#concept_jyp_21x_lr)

Putting the system into System ON IDLE while DETECT is high will not cause DETECT to wake the system up again. Make sure to clear all DETECT sources before entering sleep. If the LATCH register is used as a source, if any bit in LATCH is still high after clearing all or part of the register (for instance due to one of the PINx.DETECT signal still high), a new rising edge will be generated on DETECT, see Pin configuration.

From this description, it is not clear if our configuration would trigger the condition described above. We are not doing any specific behavior to ensure clearing of the accelerometer interrupt before going to sleep. Typically, we only go to sleep if the accelerometer has not generated an interrupt for 30 seconds.

What possible scenarios could cause the accelerometer interrupt to not be able to wake the system?

Thank you!

[Håkon Alseth]

Hi,

 

The GPIOTE PORT event has one signal, named "DETECT", which does not differentiate between pins. If this signal is set, the firmware (nrf_drv_gpiote in this case) is responsible for checking which source has triggered the signal. In mode "GPIOTE_CONFIG_IN_SENSE_TOGGLE", the nrf_drv_gpiote will also reverse the SENSE of the pin, to be able to provide a "software emulated edge triggering" (ie: event on both falling and rising edge), as compared to the level triggered operation.

In this mode, you are technically vulnerable to other interrupts (as the SoftDevice or other interrupts in your application), as you might be blocked when detecting one of the edges. As you have a pulse that is 12.5 ms, it is very unlikely that the softdevice will block this event from executing on both edges. Do you have other interrupts that might postpone the execution of the GPIOTE_IRQHandler?

You mention that these pins are configured with _SENSE_HI_TO_LO, but the code you attached is _SENSE_TOGGLE. Is the define "GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS" (located in sdk_config.h) set to the appropriate amount of GPIOTE pins configured with low accuracy?

 

Best regards,

Håkon