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.

Parents
  • 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

Reply
  • 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

Children
No Data
Related