Increased Current Consumption after GPIO Interrupt

[Christian Braun]

Hello,

We are working on an integration between a nRF52832 and ST LIS3DH accelerometer on our custom board, using SDK 15.2.0 with SoftDevice and BLE enabled, and have observed an increase in idle current draw after the first interrupt from the accelerometer after system power-up. As part of our analysis, we have isolated the accelerometer from the nRF and manually inject the interrupt on the nRF pin, as well as commenting out interrupt handling code and making the interrupt simply toggle an IO for observation with an oscilloscope, and still observe the increased current draw.

Below is the code we are using to initialize the interrupt pin. We have tested by setting the interrupt in both the low and high accuracy mode and observed a correlated ~5uA reduction in current by using the PORT interrupt mode, however the increase in current after the interrupt event is still present.

uint32_t rc = nrfx_gpiote_init();
APP_ERROR_CHECK(rc);
nrf_drv_gpiote_in_config_t accel_int_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
accel_int_config.pull = NRF_GPIO_PIN_PULLDOWN;
rc = nrf_drv_gpiote_in_init(ACCEL_INT, &accel_int_config, accel_interrupt_line_evt_handler);
APP_ERROR_CHECK(rc);
nrf_drv_gpiote_in_event_enable(ACCEL_INT, true);

Below are two charts showing the current increase with the interrupt beginning at the ~90^th data point. These interrupts were triggered manually using an external jumper, and the interrupt service was modified to perform no accelerometer interaction via TWI and simply toggle GPIO 22 for 1ms to confirm the interrupt triggered.

Any guidance in identifying the cause and addressing this issue would be greatly appreciated.

[hmolesworth]

We once hit a similar issue in SDK 15 related to Errata 89 "GPIOTE: Static 400 μA current while using GPIOTE" so the question is even though no TWI transactions occur within the interrupt does the TWI still get initialised or used at all outside the interrupt? If so maybe try not initialising TWI for the port pin test.

[Christian Braun]

Thank you for your input. We are aware of Errata 89 and have implemented the fix per the documentation. In the tests above, the TWI peripheral was still enabled and I2C interactions occurred outside the interrupt service.

We disabled the TWI peripheral in the sdk_config.h file and commented out the instantiation and relevant application code. Additionally, BLE advertising and other pieces of proprietary application code were disabled to limit other possible interactions. Unfortunately the increase in current consumption after the interrupt event is still present even under these conditions.

[Håkon Alseth]

Hi,

 

If I read your graphs correctly, you are going from approx. 20 uA -> 60 uA after the interrupt has occurred.

pin is configured with PORT, with emulated edge triggering, but you are also seeing similar behavior when using "hi_accuracy" (ie. GPIOTE.IN).

What is the sampling rate of your current profile? I fear that aliasing is causing the current consumption curve to be smoothed out, so that we loose potential wake-up events. Do you have access to a PPK2 or similar which has a higher sampling rate?

 

Kind regards,

Håkon

[Christian Braun]

Hi Håkon. You are correct, data is being aliased due to the sampling rate in the previous recordings. Attached are a .ppk2 file of the recording of a test similar to those above at 100kS/s, as well as a screenshot showing the transition period before and after the interrupt event at approximately 22.7s.

No debounce is being applied to the manually triggered interrupt. The ~2mA current spikes for ~0.2s after the interrupt can be attributed to this as a GPIO attached to a level shifter with pullups is being driven to observe and confirm the interrupt is triggered. The ~1.5s period current spikes are another processor on the board waking up periodically. I also wrapped the nrf_pwr_mgmt_run() call in main() with a GPIO toggle to observe wake events, and did not observe a difference before and after the interrupt event.

ppk2-20241220T201045.ppk2