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

    (How) do you do calibration when you've set the RC oscillator as your LF clock source? Have you enabled the CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION config? If you don't the LFRC oscillator will degrade over time. Are you able to recreate a similar difference in the current consumption on I.E. a development kit?

    Best regards,

    Simon

  • The symbols concerning calibration as per default, i.e.

    CONFIG_CLOCK_CONTROL_NRF=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
    CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_LF_ALWAYS_ON=y
    CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_PERIOD=4000
    CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_MAX_SKIP=1
    CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_TEMP_DIFF=2
    CONFIG_CLOCK_CONTROL_NRF_USES_TEMP_SENSOR=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
    CONFIG_CLOCK_CONTROL_NRF_ACCURACY=500
    


    Several tests with higher calibration period were made getting same results. 

    Tests disabling calibration setup ending in not having a device properly working. Then, I discard to use that option. 

    I can't test with a development kit cause I'm not using NRF52832 and as far as I know there is no dev kit containing NRF52805, I will require to test the current consumption on a board that contains NRF5205 instead, even though I know they are pretty similar.

  • Hi again

    Indeed, there are no DKs containing the nRF52805 but the current consumption should be similar for all nRF52 family boards. On our end, setting the three following configs to get all the power management configs right gave us the expected values on an nRF52840 at least.

    CONFIG_PM_DEEP_SLEEP_STATES=y
    CONFIG_PM_DEVICE=y
    CONFIG_PM_STATE_LOCK=y

    I'll try to get my hands on an nRF52805 SoC as well to test this myself. Please try setting the above configs on your end if you haven't already as well, to see if that decreases the current consumption at all.

    An excess current draw of ~180µA could point to the external HF crystal HFXO is kept running. Are you able to check with a scope or multimeter if there is constant activity on the HF clock pins on your device?

    Best regards,

    Simon

  • Hi Simonr, 

    I tested my hardware with symbols you suggested but didn't work, I'm still having the offset. I was able to inspect with my oscilloscope if there is any constant activity at HFXO while sleeping and even though that I wasn't able to see the expected signal on that pin I guess due my limitations on the oscilloscope, I was able to see sporadic events assuming that this is due HFXO is being awake because calibration, but it wasn't constant. 

    Were you able to test on your side with NRF52805 CAAA? 

  • Not yet tested on my end as I've been restricted to home office for a period due to quarantine. I'll test it on my end tomorrow hopefully and get back to you with any results.

    Can you also specify how exactly the HFXO current didn't seem constant? Does it start up at certain times matching the calibration interval for instance? Because that would make sense if there's a bug with the calibration not being stopped when the system is turned off.

    Best regards,

    Simon

Related