Help Reducing Sleep Current While Keeping RTC Active

RE: Help Reducing Sleep Current While Keeping RTC Active

Kenneth — Mon, 03 Feb 2025 09:54:11 GMT

Hello,

The only thing I can can think of is what you have configured REGOUT0 to?
https://docs.nordicsemi.com/bundle/ps_nrf52840/page/power.html
https://docs.nordicsemi.com/bundle/ps_nrf52840/page/uicr.html#ariaid-title69

Make sure REGOU0 is <VDDH-0.3V.

Kenneth

RE: Help Reducing Sleep Current While Keeping RTC Active

Arthur J Sary — Fri, 31 Jan 2025 12:02:46 GMT

Hello Kenneth,

Thank you so much for the advice regarding the HFCLK. Disabling it once I finish sampling really resolved the high current issue, and I’m now seeing about 2.9 µA during sleep. However, I’ve encountered another related challenge.

I’m using a 3.7V LiPo battery (hence High Voltage mode), but when testing on a bench power supply, I’ve noticed that the sleep current varies significantly depending on the supply voltage. Here are the sleep current measurements I observed:

3.6V: ~3 µA
3.3V: ~50 µA
3.0V: ~700 µA

To gather these measurements, I perform a single cycle test: I remove power from the system, change the power supply voltage, then re-energize at the new voltage.

Do you have any suggestions on what might be causing these discrepancies at different voltages, and how I can address them? Thank you for any guidance you can provide.

Best regards,

RE: Help Reducing Sleep Current While Keeping RTC Active

Kenneth — Tue, 28 Jan 2025 17:07:07 GMT

[quote user="Arthur J Sary"]Regarding Bluetooth, I haven’t found any examples in the nRF Connect SDK or Zephyr that specifically use bt_disable(). Could you advise on the proper way to fully turn off Bluetooth to minimize power consumption when it’s not needed?[/quote]

There is no need to disable bt to achieve the 2.7uA idle current. Actually even with BT active in connection or advertisment, you will still get 2.7uA in between BLE events.

[quote user="Arthur J Sary"]Additionally, I use the high-frequency clock (HFCLK) for sampling during normal operation. I’m enabling it with the code snippet below. How should I properly turn off or release the HFCLK once I’m done, to reduce power consumption further?[/quote]

Starting the HFCLK will likely cause the 400-500uA you see. Based on the code snippet you shared, I would expect onoff_request() has an onoff_release() api.

Kenneth

RE: Help Reducing Sleep Current While Keeping RTC Active

Arthur J Sary — Tue, 28 Jan 2025 16:38:20 GMT

Hello Kenneth,

When I mentioned “deep sleep,” I was referring to a low-power, system-on mode with the RTC active. I’ve tested disabling the RX lines for any unneeded UART interfaces, and I’m also using pm_device_action_run(...) to suspend all the serial peripherals, but I’m still seeing around 450 µA.

Regarding Bluetooth, I haven’t found any examples in the nRF Connect SDK or Zephyr that specifically use bt_disable(). Could you advise on the proper way to fully turn off Bluetooth to minimize power consumption when it’s not needed?

Additionally, I use the high-frequency clock (HFCLK) for sampling during normal operation. I’m enabling it with the code snippet below. How should I properly turn off or release the HFCLK once I’m done, to reduce power consumption further?


static int enable_high_frequency_clock(void)
{
	int err = 0;
	int res = 0;
	struct onoff_manager *clk_mgr;
	struct onoff_client clk_cli;

	clk_mgr = z_nrf_clock_control_get_onoff(CLOCK_CONTROL_NRF_SUBSYS_HF);
	if (!clk_mgr)
	{
		LOG_ERR("Unable to get the Clock manager");
		return -ENXIO;
	}

	sys_notify_init_spinwait(&clk_cli.notify);

	err = onoff_request(clk_mgr, &clk_cli);
	if (err < 0)
	{
		LOG_ERR("Clock request failed: %d", err);
		return err;
	}

	do {
		err = sys_notify_fetch_result(&clk_cli.notify, &res);
		if (!err && res)
		{
			LOG_ERR("Clock could not be started: %d", res);
			return res;
		}
	} while (err);

	LOG_INF("HF clock started");
	return 0;
}

RE: Help Reducing Sleep Current While Keeping RTC Active

Kenneth — Tue, 28 Jan 2025 11:57:28 GMT

I think most examples in the nRF Connect SDK are power somewhat power optimized as long as you disable logging by for instance CONFIG_SERIAL=n. Once you enable any kind of logging, then achieving low power is likely not that easily possible no, though you can try the trick I suggested with disable-rx; for the uart node for logging.

However you mention deep sleep, in this mode the only wakeup source is nfc or pin toggling, there is no rtc wakeup in this mode. Deep sleep is entered by calling sys_poweroff().

Kenneth

RE: Help Reducing Sleep Current While Keeping RTC Active

Arthur J Sary — Mon, 27 Jan 2025 17:14:04 GMT

Hello Kenneth,

Could you please provide or point me to an example that uses Bluetooth and then properly transitions into a low power/deep sleep mode? I want to confirm that I’m disabling Bluetooth correctly in my application, and having a reference example would really help me compare my approach.

Thank you in advance!

RE: Help Reducing Sleep Current While Keeping RTC Active

Arthur J Sary — Mon, 27 Jan 2025 14:55:39 GMT

Hello Kenneth,

Thanks for confirming that the pm_device_action_run(uart1_dev, PM_DEVICE_ACTION_SUSPEND) call should handle disabling the UART. If that’s working as intended, it seems unlikely to be the source of the ~450 µA we’re still measuring in sleep mode, since we’re already calling pm_device_action_run(...) on all relevant peripherals.

Additionally, I noticed that zephyr_console is bound to uart0, so I used pm_device_action_run(console_dev, PM_DEVICE_ACTION_SUSPEND) to suspend the console device. This should also disable uart0, right? Or do I need to explicitly disable the UART0 with pm_device_action_run too?

We’re still seeing ~450 µA even with the serial interfaces disabled. If you have any further suggestions on what else might be contributing to the current draw, I’d be grateful.

Thank you for your continued help!

RE: Help Reducing Sleep Current While Keeping RTC Active

Kenneth — Mon, 27 Jan 2025 14:29:25 GMT

[quote user="Arthur J Sary"]Shouldn’t this command automatically disable everything possible (including the RX pin) to ensure the lowest power consumption? [/quote]

I would expect that to work yes.

Kenneth

RE: Help Reducing Sleep Current While Keeping RTC Active

Arthur J Sary — Mon, 27 Jan 2025 13:19:04 GMT

Hello Kenneth,

Thank you very much for your response and for the references you provided!
I have a question regarding the UART suspend behavior. When using the following command to suspend the UART:

const struct device *const uart1_dev = DEVICE_DT_GET(DT_NODELABEL(uart1));
rc = pm_device_action_run(uart1_dev, PM_DEVICE_ACTION_SUSPEND);

Shouldn’t this command automatically disable everything possible (including the RX pin) to ensure the lowest power consumption? Or do I still need to explicitly add disable-rx in the device tree to ensure the RX pin is turned off?

Thank you in advance for your help!

Best regards,

RE: Help Reducing Sleep Current While Keeping RTC Active

Kenneth — Mon, 27 Jan 2025 12:10:11 GMT

Hello,

If you haven't already I recommend to go through Lesson 7 in our DevAcademy course:
https://academy.nordicsemi.com/courses/nrf-connect-sdk-fundamentals/lessons/lesson-7-multithreaded-applications/

There is also a Power Optimization chapter in the nRF Connect SDK:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/test_and_optimize/optimizing/power.html

Also, in general if you are using uart, the main challenge is the current consumption when in rx mode, so if you just need uart for logging, you can disable rx mode by adding e.g.:

/* Disabling uart rx pin to get low power */
&uart0 {

disable-rx;
};

Best regards,
Kenneth