Random ~265uA extra current consuption when NRF52832 is in sleep mode.

[Luis]

Hello, we have a product that uses the NRF52832. We recently detected that the device will randomly increase its current consumption by about 260uA during sleep mode. Once this extra current consumption starts, we can only eliminate it with a soft reset. Interestingly, it doesn't seem to recur after that reset, though previous resets do not prevent the issue from happening. We've also noticed that the extra current consumption is only present when the device is in sleep mode; it does not occur when the processor is active and running. Our primary suspicion is that some peripheral of the NRF52832 remains active during sleep mode and fails to turn off. Is there any way to check what remains on during a sleep event? We tried to debug, but it only emulates the sleep event, which is essentially the same as the run mode. Are there any likely candidates that would consume such current? 

Thank you!

EDIT:

Adding more information:

I am using NRF5 SDK 15.3.0

EDIT2:

Adding a bit more of information. I tested to add a standard timer to ran continuously and measured the current. The current goes up as expected as the timer is on during the sleep (idle) mode. However the extra 265uA never comes again, so it looks like that something is forcing the HFCLK to stay on during the sleep mode. Weirdly I do not directly use the HFCLK for nothing. Probably only the SoftDevice uses it for the BLE connection. Is there anyway to check what is making the HFCLK stay on. I tryed to look into all registers of the device but could not find anything. 

Thank you!

[hmolesworth]

Maybe use HFCLKSTAT to see if it running periodically; if not needed issue HFCLKSTOP. Unfortunately there is no STOPPED event, but it is possible to see if it unexpectedly started:

Event:  CLOCK->EVENTS_HFCLKSTARTED      0x4000'0100 = 1 (No Enable Field)       IntEnable 0x4000'0300=         0
Event:  CLOCK->EVENTS_LFCLKSTARTED      0x4000'0104 = 1 (No Enable Field)       IntEnable 0x4000'0300=         0

[Luis]

I tested stoping the HFCLK right before going to sleep mode but it crashes the software. I guess it is something I cannot do when using the SoftDevice. 

[Nguyen Hoan Hoang]

Do you know that the HFCLK is used by UART, SPI, I2C ?

Turn your SPI, I2C off as I showed you to see what would happen. 

[hmolesworth]

If using the softdevice have to go via the API to avoid a crash "If a SoftDevice is running, the clock is managed by the SoftDevice and all requests are handled by the SoftDevice. This function cannot be called from all interrupt priority levels in that case"

[Luis]

Hello All, 

Just to add more information:

Follow a minimal version that will bring the problem:

/**
 * @file main.c
 */

#include <inttypes.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include "app_timer.h"
#include "nordic_common.h"
#include "nrf.h"
#include "nrf_ble_lesc.h"
#include "nrf_delay.h"
#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"
#include "nrf_pwr_mgmt.h"
#include "nrf_sdh.h"
#include "nrf_drv_timer.h"
#include "bsp.h"
#include "app_timer.h"

APP_TIMER_DEF(m_reset_timer_id);

static void reset_timer_handler(void *p_context) {
  sd_nvic_SystemReset();
}

/**
 * @brief Initialize all the required modules and the application layer.
 */
void setup(void)
{

    NRF_CLOCK->LFCLKSRC = (CLOCK_LFCLKSRC_SRC_Xtal << CLOCK_LFCLKSRC_SRC_Pos)|(CLOCK_LFCLKSRC_BYPASS_Enabled << CLOCK_LFCLKSRC_BYPASS_Pos ) |
     (CLOCK_LFCLKSRC_EXTERNAL_Enabled << CLOCK_LFCLKSRC_EXTERNAL_Pos);

    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0; 
    NRF_CLOCK->TASKS_LFCLKSTART = 1;
    while(NRF_CLOCK->EVENTS_LFCLKSTARTED == 0)
    {//do nothing
    }

    nrf_gpio_input_disconnect(BSP_DEF_VBAT_M_PIN);

    // FLASH_CS
    nrf_gpio_cfg_output(BSP_DEF_FLASH_CS_PIN);
    nrf_gpio_pin_write(BSP_DEF_FLASH_CS_PIN, 1);

    // ACCEL_INT
    nrf_gpio_cfg_input(BSP_DEF_ACCEL_INT_PIN, GPIO_PIN_CNF_PULL_Disabled);

    // ACCEL_CS
    nrf_gpio_cfg_output(BSP_DEF_ACCEL_CS_PIN);
    nrf_gpio_pin_write(BSP_DEF_ACCEL_CS_PIN, 1);

    // LED
    nrf_gpio_cfg_output(BSP_DEF_LED_RED_PIN);
    nrf_gpio_pin_write(BSP_DEF_LED_RED_PIN, 1);
        // LED
    nrf_gpio_cfg_output(BSP_DEF_LED_GREEN_PIN);
    nrf_gpio_pin_write(BSP_DEF_LED_GREEN_PIN, 1);
    
        // LED
    nrf_gpio_cfg_output(BSP_DEF_LED_BLUE_PIN);
    nrf_gpio_pin_write(BSP_DEF_LED_BLUE_PIN, 1);

    // VBAT_M_EN
    nrf_gpio_cfg_output(BSP_DEF_VBAT_M_EN_PIN);
    nrf_gpio_pin_write(BSP_DEF_VBAT_M_EN_PIN, 0);

    // BAT_CHARGED
    nrf_gpio_cfg_input(BSP_DEF_BAT_CHARGED_PIN, GPIO_PIN_CNF_PULL_Pullup);
    nrf_gpio_cfg_input(BSP_DEF_LSEN_INT_PIN, GPIO_PIN_CNF_PULL_Pullup);
    nrf_gpio_cfg_input(BSP_DEF_VAUX_MONITOR_PIN, GPIO_PIN_CNF_PULL_Pullup);
  
    uint32_t err_code = app_timer_init();
    APP_ERROR_CHECK(err_code);

    app_timer_create(&m_reset_timer_id,
                                  APP_TIMER_MODE_SINGLE_SHOT,
                                  reset_timer_handler);
    app_timer_start(m_reset_timer_id, APP_TIMER_TICKS(30000), NULL);
}

/**
 * @brief Main loop.
 */

int main(void)

{
    setup();
    while (1)
    {
        // Wait for an event.
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }
}

The GPIOs configuration is specific from my board. The problem happens when you power cycle the board and wait a few reset cycles. When it happen it will go away most of the times with another reset so will star just for a few seconds. 

Any idea of the cause of the problem? I am convinced that it is related of the use of the external clock with bypass. 

Best