This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

High current consumption offset when using internal RC oscillator as compared to crystal oscillator for low frequency clock.

Describe the bug

When trying to sleep core on NRF52805 using low frequency internal rc oscillator, average current consumption is ~189.50 uA while when using external crystal oscillator, average current consumption is ~ 8 uA. 

I can't provide actual application code that I'm running, however, the only difference at Kconfig level it's whether to decide which low frequency crystal is used. I tried to get into the errata section to find out if it was something related to it but it doesn't. Also, I do not have UART enabled, and verification have been made to confirm that there is no GPIO line floating. 

How to reproduce

Chip model: NRF52805 CAAA

os: Linux / GNU

sdk-nrf tag: v1.5.1, v1.4.0

Microcontroller is using System ON and DC-DC is enabled

  • Use internal rc crystal oscillator
    • remove extra capacitors and crystal connected to xtal pins
    • leave extra capacitors and crystal connected to xtal pins
  • Measure current consumption going into NRF52805
  • prj.conf:
    • CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
      CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
      CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n
  • Extra configurations:
    • CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_LF_ALWAYS_ON=n
  • When device sleeps and debugger is connected these are the register values:
    • Fields in CLOCK > LFCLKSTAT:
      SRC: RC 32.768 kHz RC oscillator - Source of LFCLK
      STATE: Running LFCLK running - LFCLK state
      Fields in CLOCK > HFCLKSTAT:
      SRC: RC 64 MHz internal oscillator (HFINT) - Source of HFCLK
      STATE: Running HFCLK running - HFCLK state
      Fields in CLOCK > LFCLKSRC:
      SRC: RC 32.768 kHz RC oscillator - Clock source
      Fields in CLOCK > HFCLKSTAT:
      SRC: RC 64 MHz internal oscillator (HFINT) - Source of HFCLK
      STATE: Running HFCLK running - HFCLK state

One way to quickly reproduce the behavior it's modifying system off sample on zephyr samples: 

/*
 * Copyright (c) 2019 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <stdio.h>
#include <zephyr.h>
#include <device.h>
#include <init.h>
#include <power/power.h>
#include <hal/nrf_gpio.h>

#define CONSOLE_LABEL DT_LABEL(DT_CHOSEN(zephyr_console))

/* Prevent deep sleep (system off) from being entered on long timeouts
 * or `K_FOREVER` due to the default residency policy.
 *
 * This has to be done before anything tries to sleep, which means
 * before the threading system starts up between PRE_KERNEL_2 and
 * POST_KERNEL.  Do it at the start of PRE_KERNEL_2.
 */
static int disable_ds_1(const struct device *dev)
{
	ARG_UNUSED(dev);

	pm_ctrl_disable_state(POWER_STATE_DEEP_SLEEP_1);
	return 0;
}

SYS_INIT(disable_ds_1, PRE_KERNEL_2, 0);

void main(void)
{
	int rc;
	uint8_t i;
	const struct device *all_devices;
	static volatile uint16_t devices_count;
	devices_count = z_device_get_all_static(&all_devices);

	for(i = 0; i < devices_count; ++i)
	{
		rc = device_set_power_state(&(all_devices[i]), DEVICE_PM_LOW_POWER_STATE, 0, 0);
	}
	k_sleep(K_MSEC(1000000));

	printk("ERROR: System off failed\n");
	while (true) {
		/* spin to avoid fall-off behavior */
	}
}

Expected behavior

To have similar results on current consumption as when using external crystal oscillator with slightly offset.

  • Hi again

    I have tested an nRF52805 today running the RC oscillator on the beacon example in NCS v1.5.1 and I'm afraid I was not able to see the high current consumption you're seeing on your end. I have run the example both on an nRF52832 DK and an nRF52805 board and saw similar current consumption when the devices were turned off.

    This leads me to think that something in your application is causing this extra current consumption, but it's hard to tell what exactly. The changes I made to the beacon project on my end was adding the following lines to my prj.conf file, and removing the DEVELOP_IN_NRF52832 definition in CMakeLists.txt.

    CONFIG_BT_DEVICE_NAME="Beacon_805"
    CONFIG_PM_DEEP_SLEEP_STATES=y
    CONFIG_PM_DEVICE=y
    CONFIG_PM_STATE_LOCK=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

    I can send you a .hex file as well if you'd like to test on your end to confirm that your HW is not drawing the excess current.

    Best regards,

    Simon

  • Simonr, thanks for digging into this. 

    Would you mind to send the hex file so I can test it here on my end? 

  • 4857.zephyr.hex

    Here you are. Please let me know what current consumption you see when this is advertising and asleep.

    Best regards,

    Simon

  • Simonr, 

    After flashing the binary into device I got the following:

    - A peak around 5 uA every 333 ms

    - 0.13 uA in average current consumption for about 274 ms

    I was inspecting if device were advertising but it's not. This can be confirmed as well due the fact that I don't see a high peak around mA. Would you confirm this?

    Based on these results I guess it's something on my firmware that's causing the issue. However, I would
    like to know from which sdk commit have you compiled this image along along with all the symbol parameters (final .config file on zephyr folder) cause when I tried at the very first stage, I couldn't reach that current consumption.

    My plan is to replicate same results from source here at lab and track the issue down with my own firmware.

    In either or other way, what you have tested help me to confirm that it's not a hardware issue. Thanks again,

  • Hi again

    Sure, I took the beacon sample from Zephyr in NCS v1.5.1 and only added these defines to the prj.conf file, and edited it to go straight to sleep instead of starting advertising. I don't have the exact snippet here as I'm on a different computer today.

    CONFIG_PM_DEEP_SLEEP_STATES=y
    CONFIG_PM_DEVICE=y
    CONFIG_PM_STATE_LOCK=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    

    Best regards,

    Simon

Related