Unexpected consumption using System OFF Sample & nRF52840DK

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Tue, 23 Jan 2024 10:45:38 GMT

I suggest changing the UART1 status to 'disabled' in your custom board files, removing the need to create overlays for your project. Same as we did for the nrf52840dk_nrf52840 board in more recent SDK releases.

It is possible to apply named overlays to child images as well by passing CMake symbols to the build. E.g.

/*Build MCUboot with disable_uart1.overlay */
-Dmcuboot_DTC_OVERLAY_FILE=disable_uart1.overlay

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/config_and_build/multi_image.html#image-specific-variables

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Tue, 23 Jan 2024 09:41:37 GMT

Indeed, the uart1 was enabled for the MCUBoot, so using an overlay file I disabled it ( also made sure by checking /build/mcuboot/zephyr/zephyr.dts.)!

Thank you very much for your support in tracking down this unexpected source of consumption it was crucial for my application!

One last a bit trivial question:

I am using an overlay file to disable the uart1, which is setup in my application directory under child_image/mcuboot/boards/nrf52840dk_nrf52840.overlay. Is it possible to use an overlay file with a more generic name so I can apply it to all my custom boards for example mcuboot.overlay, similar to the child_image/mcuboot.conf overlay I am using for the configuration options of the MCUBoot?

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Tue, 23 Jan 2024 07:49:25 GMT

Did you ensure that UART1 is also disabled in the device tree used to build the bootloader? You can check whether it is enabled or disabled in /build/mcuboot/zephyr/zephyr.dts.

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Mon, 22 Jan 2024 15:34:44 GMT

So after a lot of testing and different trial and error tests, I found that the culprit was the Serial of the MCUBoot that was enabled and when disabled in the mcuboot.conf overlay file I have in my application (child_image/mcuboot.conf). After I added the CONFIG_MCUBOOT_UART=n & CONFIG_SERIAL=n the consumption fell to the expected numbers I was seeing in the samples when the UART was properly disabled.

So now my main question is:

Is there a way to be able to have Serial recovery with the MCUBoot but be able to have the serial properly disabled when the application is loaded? Could I disable the UART (UART pin config) manually during the initialization of my application?

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Mon, 22 Jan 2024 15:02:59 GMT

Apparently disabling the MCUMgr fixes the issue, but the thing is I need the MCUMgr for DFU(I am guessing it implicitly enables something the increases the consumption maybe it is the UART) so is there a way (configuration option for example) to disable this increased consumption without disabling the whole MCUMgr (UART for the MCMgr is already disabled CONFIG_MCUMGR_SMP_UART=n) ?

I am still investigating this on my own so I might be able to figure it out but I would still appreciate any hints or tips on this issue.

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Mon, 22 Jan 2024 13:43:46 GMT

Hi Vidar,

Thank you for your response, I took your consideration into account.

[quote userid="4240" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/465131"]You also mention having some sensors, are they included in the measurement or powered separately?[/quote]

Sorry for misleading in my previous message, what I meant was I don't have any peripherals or sensors connected to the I2C bus of the DK, actually, I do not have anything connected to the DK (apart from the PPK2 for the measurement).

In our custom FW, I have disabled all sensors and I2C transactions except for one I2C peripheral that is not connected which tries and fails to communicate with it. Besides this and the initialization of the BLE stack and advertising, there are no other processes running after this. I have checked the execution flow with the debugger and after the initialization of the BLE stack and advertisement no thread is running.

[quote userid="4240" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/465131"]Have you tried to not enabling these sensors?[/quote]

I have also tried commenting out any other piece of code in the initialization of our custom FW leaving only the BLE stack initialization and BLE advertisement start.

The results are the same and the increased consumption is still present.

Could you please take a look at the configuration options of our application to check whether something on here can cause this increased consumption.

prj.conf

################################################################################
## Zephyr Configuration

#########################################################
# Libraries & Peripherals configuration

# Enable the UART driver
CONFIG_UART_ASYNC_API=n
CONFIG_NRFX_UARTE0=n

# Enable the GPIO module
CONFIG_GPIO=y

# Enable the I2C module
CONFIG_I2C=y
CONFIG_I2C_NRFX=y
CONFIG_CBPRINTF_FP_SUPPORT=y

# Make sure printk is printing to the RTT console
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y

# Enable the SPI module
CONFIG_SPI=y
CONFIG_SPI_NRFX=y

# Enable the Date/Time library
CONFIG_DATE_TIME=y
# CONFIG_DATE_TIME_UPDATE_INTERVAL_SECONDS=2147483647
# CONFIG_DATE_TIME_TOO_OLD_SECONDS=10 
# CONFIG_DATE_TIME_MODEM=n
CONFIG_DATE_TIME_NTP=n
CONFIG_DATE_TIME_LOG_LEVEL_DBG=n
# CONFIG_DATE_TIME_LOG_LEVEL_WRN=y

# Enable the Reboot functionality
CONFIG_REBOOT=y

# Enable the HW Information module
CONFIG_HWINFO=y

#########################################################
# System Stack Sizes configuration

# Increased the stack for the MCUmgr & History Module
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=5096
# CONFIG_MPSL_WORK_STACK_SIZE=2048
# CONFIG_SHELL_STACK_SIZE=2048
# CONFIG_IDLE_STACK_SIZE=2048
# CONFIG_MAIN_STACK_SIZE=4096
# CONFIG_ISR_STACK_SIZE=4096
# CONFIG_PRIVILEGED_STACK_SIZE=2048
# CONFIG_BT_LONG_WQ_STACK_SIZE=2048

# Configure the HEAP Memory Size
CONFIG_HEAP_MEM_POOL_SIZE=4096

# CONFIG_TIMESLICING=n

#########################################################
# Power Management configuration

# Enable Power Management
CONFIG_PM=y

# Enable to use the System OFF State
CONFIG_PM_DEVICE=y

#########################################################
# Flash File System configuration
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y
CONFIG_FS_LOG_LEVEL_INF=y
CONFIG_NVS_LOG_LEVEL_WRN=y

# SPI NOR configuration
# CONFIG_SPI_NOR=y
# CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

# Partition Manager Setttings
# CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n

#########################################################
# Task Watchdog configuration
CONFIG_WATCHDOG=y
CONFIG_WDT_LOG_LEVEL_WRN=y
CONFIG_WDT_DISABLE_AT_BOOT=y
CONFIG_TASK_WDT=y
CONFIG_TASK_WDT_CHANNELS=15
CONFIG_TASK_WDT_HW_FALLBACK=n
# CONFIG_TASK_WDT_MIN_TIMEOUT=1000
# CONFIG_TASK_WDT_HW_FALLBACK_DELAY=1000


#########################################################
# BLE stack configuration
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="Nordic_UART_Service"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_MAX_CONN=1
CONFIG_BT_MAX_PAIRED=1
CONFIG_BT_DEVICE_NAME_DYNAMIC=y

# Thread Stack Sizes
# CONFIG_BT_LONG_WQ=y
# CONFIG_BT_LONG_WQ_STACK_SIZE=2048

# Enable Logging for the BLE stack
# CONFIG_BT_LOG_LEVEL_DBG=y
# CONFIG_BT_NUS_LOG_LEVEL_DBG=y
# CONFIG_BT_CONN_CTX=y
# CONFIG_BT_CONN_CTX_LOG_LEVEL_DBG=y

# CONFIG_BT_CONN_TX_MAX=100
# CONFIG_BT_L2CAP_TX_BUF_COUNT=100
CONFIG_BT_BUF_ACL_TX_COUNT=50

CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251

# CONFIG_BT_L2CAP_TX_MTU=252
# CONFIG_BT_BUF_ACL_TX_SIZE=256
# CONFIG_BT_BUF_ACL_RX_SIZE=256

# CONFIG_BT_L2CAP_TX_MTU=498
# CONFIG_BT_BUF_ACL_RX_SIZE=502
# CONFIG_BT_BUF_ACL_TX_SIZE=502

# CONFIG_BT_PRIVACY=y #DO NOT ENABLE THIS BECAUSE DFU WILL NOT WORK 

# This does the same job as manual update_connection_parameters() function
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=n
# CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=y
# CONFIG_BT_PERIPHERAL_PREF_MIN_INT=15
# CONFIG_BT_PERIPHERAL_PREF_MAX_INT=15
# CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=400


# CONFIG_BT_LOG_SNIFFER_INFO=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CONN_PARAM_UPDATE_TIMEOUT=300
CONFIG_BT_USER_PHY_UPDATE=y
CONFIG_BT_GATT_CLIENT=y
# CONFIG_BT_GATT_AUTO_UPDATE_MTU=y # Use the manual update for better throughput
CONFIG_BT_USER_DATA_LEN_UPDATE=y

# CONFIG_BT_HCI_ACL_FLOW_CONTROL=y

# Enable the NUS service
CONFIG_BT_NUS=y
# CONFIG_BT_NUS_LOG_LEVEL_DBG=y

# Enable for proper BLE operation
CONFIG_BT_SETTINGS=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

# Enable pairing with static passkey & bonding
# CONFIG_BT_NUS_SECURITY_ENABLED=y
# CONFIG_BT_NUS_AUTHEN=y
# CONFIG_BT_SMP=y
# CONFIG_BT_SMP_SC_ONLY=y
# CONFIG_BT_FIXED_PASSKEY=y
# CONFIG_BT_BONDABLE=y
# CONFIG_BT_TINYCRYPT_ECC=y


#########################################################
# MCU Manager for DFU functionality configuration

# Enable mcumgr.
CONFIG_MCUMGR=y

# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y
# CONFIG_MCUMGR_CMD_STAT_MGMT=y

# Ensure an MCUboot-compatible binary is generated.
# NSIB as immutable first-stage & MCUBoot as Upgradable
# CONFIG_SECURE_BOOT=y
# CONFIG_SB_SIGNING_KEY_FILE="C:/ncs/feel_v2_fw/feel_v2_fw/child_image/keys/feel_sign_priv.pem"
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_IMAGE_VERSION="0.18.0+1"

# Enable the serial mcumgr transport.
CONFIG_MCUMGR_SMP_UART=n
# Enable USB subsystem
# CONFIG_USB_DEVICE_STACK=y
CONFIG_SERIAL=n
# CONFIG_UART_LINE_CTRL=n

# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
# CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y

# # Required by the `taskstat` command.
# CONFIG_THREAD_MONITOR=y

# # Enable statistics and statistic names.
# CONFIG_STATS=y
# CONFIG_STATS_NAMES=y

#########################################################
# Logger configuration
CONFIG_LOG=n
# CONFIG_USE_SEGGER_RTT=y
# CONFIG_LOG_BACKEND_RTT=y
# CONFIG_LOG_BACKEND_UART=n

# Increase if logging thread is at its limit
CONFIG_LOG_BUFFER_SIZE=8192
CONFIG_LOG_PROCESS_THREAD=y
CONFIG_LOG_SPEED=y
CONFIG_LOG_PROCESS_THREAD_STACK_SIZE=4096

# CONFIG_LOG_PRINTK=y

# For debugging watchdog resets please use the IMMEDIATE mode (only)
# all other times use the DEFERED (default) mode by commenting out this option
# CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_ASSERT=n
#########################################################
# Thread Analyzer configuration
# CONFIG_THREAD_ANALYZER=y
# CONFIG_THREAD_ANALYZER_AUTO=y
# CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5
# CONFIG_THREAD_ANALYZER_USE_LOG=y
CONFIG_THREAD_NAME=y

Essentially I have enabled the I2C, SPI, Watchdog, Reboot, HW info, Date/Time, PM, PM Device, LittleFS for the internal flash, BLE, NUS & MCUMgr.

Could some of this be the cause for this increased consumption?

To sum up, I have disabled all initialization code except for the BLE init & advertise, have checked that nothing else is being executed after this, have the CONFIG_SERIAL=n disabled, and have checked that the output (.conf ) file has it disabled correctly and I still get the increased consumption with the same exact current curve between advertising events as I had in the beacon sample before disabling the UART correctly.

So I am assuming since I have no other devices connected to the DK it could be a floating input?

Thank you and I look forward to hearing from you!

Best regards,
Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Fri, 19 Jan 2024 17:44:07 GMT

Hi Stavros,

[quote userid="113452" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/465115"]I do not. But it has exactly the same current curve and current levels that I see with the samples (UART enabled)[/quote]

This suggests that the UART is not the culprit. There are several things that have a similar power profile to the UART. You also mention having some sensors, are they included in the measurement or powered separately?

[quote userid="113452" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/465115"]Could it be some other peripheral that is enabled, like SPI or I2C? Any input or hint is very helpful on this, or how I could go about debugging this.[/quote]

Likely not from I2C or SPI peripherals themselves, but it could be floating inputs or current drawn from the devices connected to these buses. Have you tried to not enabling these sensors?

Best regards,

Vidar

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Fri, 19 Jan 2024 16:22:34 GMT

[quote userid="4240" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/465070"]To be sure the ~500 uA is from the UART, do you get the expected idle current if you build with CONFIG_SERIAL=n[/quote]

I do not. But it has exactly the same current curve and current levels that I see with the samples (UART enabled)

Beacon System Sleep between advertising events

My custom FW (essentially just initializes some sensors which are not present in the DK and at this point its just a connectable BLE device that just advertises every 100 msec, not much different in terms of execution than the beacon. There is no other execution that is performed at this point only BLE advertise)

These are identical, for me it is for sure the UART.

What else could cause this current curve/consumption between advertising events ( where the device does nothing else but BLE advertise)? Could it be some other peripheral that is enabled, like SPI or I2C? Any input or hint is very helpful on this, or how I could go about debugging this.

Thank you very much

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Fri, 19 Jan 2024 14:00:55 GMT

Hi Stavros,

Glad to hear that it worked now.

[quote userid="113452" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/465057"]Is there a way to check (e.g. from the output files like .conf or the Compiled DeviceTree Output) if a UART module is still enabled?[/quote]

Yes, you can check the generated zephyr.dts in build/zephyr to see whether the uart1 node is enabled or not.

To be sure the ~500 uA is from the UART, do you get the expected idle current if you build with CONFIG_SERIAL=n

Best regards,

Vidar

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Fri, 19 Jan 2024 13:26:56 GMT

Hi Vidar,

I tested the System Off modified sample with an nrf52840dk_nrf52840.overlay file with the lines you suggested and it worked!

The consumption is now on the correct/expected levels! Thank you!

Unfortunately, I am still trying to fix this issue on my custom fw application, I have gone through all the steps of making sure to suspend the UART and disable uart1 but I am still getting this increased consumption (exactly the same current curve as when a UART peripheral is enabled) which is clearly a UART peripheral still enabled.

Is there a way to check (e.g. from the output files like .conf or the Compiled DeviceTree Output) if a UART module is still enabled?

Thank you and I look forward to hearing from you

Best regards,

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Thu, 18 Jan 2024 14:14:46 GMT

Hi Stavros,

The main goal of attempting to build the project with a newer SDK version was to help narrow down the issue. I've just done that, and it think I've found the culprit; until SDK v2.4.0, the nRF52840 DK board file had the UARTE1 instance enabled by default. The PM action only disables the UARTE0 instance, which is assigned to the Zephyr console.

Solution:

Create a DT overlay (nrf52840dk_nrf52840.overlay) that disabled the UARTE1 instance:

&uart1 {
    status = "disabled";
};

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Thu, 18 Jan 2024 13:44:42 GMT

Hi Vidar,

I have run the System Off & Beacon samples without any changes as I did previously and also by disabling the UART during build (CONFIG_UART=n). It is clear that the issue is the UART not being suspended, as you can see the power consumption drops to the expected values when disabled.

System Off sample - unmodified

Zoomed in the System Sleep (System ON Idle) state

System Off sample - built with UART disabled (CONFIG_SERIAL=n)

immediately you can see the difference in the SYstem ON Idle portions of the execution.

Zoomed in the System Sleep (System ON Idle) state

As you can see the System ON Idle (system Sleep) portion o f the sample has the expected values (same current curve and values as the system_on_demo.hex you provided) and significantly less power consumption. This is also observed for the beacon sample shown below.

Beacon sample - unmodified

Zoomed in the System Sleep (System ON Idle) state between the advertising events

Beacon sample - built with UART disabled (CONFIG_SERIAL=n)

Zoomed in the System Sleep (System ON Idle) state between the advertising events

Again the power consumption is significantly less and aligns with the current values reported by the datasheet

Now I want to find the way to disable/suspend the UART module during runtime correctly as the

pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);

function does not seem to work properly.

I will need to be able to do this in the current SDK version (v2.1.0) because migrating to the v2.5.1 only because I want to suspend the UART during runtime will be very time-consuming.

So my question is how is it possible to suspend the UART correctly in the v2.1.0 version of the SDK?

I will try of course your suggestion but I should be able to properly suspend the UART in v2.1.0 as well unless that is a bug in the NCS which will require extensive modifications to patch. I would like to keep working with v2.1.0 unless it's absolutely necessary and no other way is possible but to migrate to a newer version. Also if there is a fix I can apply to my version of NCS that would be great or if you have any alternatives o suggest.

Thank you for your support and I look forward to hearing from you!

Best regards,

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Thu, 18 Jan 2024 13:08:56 GMT

Please try to build the sample against a newer SDK version and see if you still experience the high idle current after suspending the UART. For example, v2.5.1.

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Wed, 17 Jan 2024 15:09:12 GMT

The commit you mentioned removed the previous 4 states (Busy Wait 2 seconds, Busy Wait UART off 2 seconds, System Sleep, System Sleep UART off) and only put the device in System Off mode. The state I am interested in measuring the consumption for is the 4th state (System Sleep aka System ON Idle or Idle current) not the System OFF ( I do not use the System Off mode in my application at all so it totally irrelevant to me).

Also I tried commenting out line 85 and I get the same current curves as the ones shown above (no change).

I also tried commenting out lines 85, 83 & 77 but I get the same result again.

I also tried commenting out lines 85, 83, 77 & 75 and adding the UART suspend in the beginning as shown in the code below but also got the same results as my previous post.

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

#include <stdio.h>
#include <zephyr/zephyr.h>
#include <zephyr/device.h>
#include <zephyr/init.h>
#include <zephyr/pm/pm.h>
#include <zephyr/pm/device.h>
#include <zephyr/pm/policy.h>
#include <soc.h>
#include "retained.h"
#include <hal/nrf_gpio.h>

#define BUSY_WAIT_S 2U
#define SLEEP_S 2U

/* 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_policy_state_lock_get(PM_STATE_SOFT_OFF, PM_ALL_SUBSTATES);
	return 0;
}

SYS_INIT(disable_ds_1, PRE_KERNEL_2, 0);

void main(void)
{
	int rc;
	const struct device *cons = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));

	if (!device_is_ready(cons)) {
		printk("%s: device not ready.\n", cons->name);
		return;
	}

	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);

	printk("\n%s system off demo\n", CONFIG_BOARD);

	if (IS_ENABLED(CONFIG_APP_RETENTION)) {
		bool retained_ok = retained_validate();

		/* Increment for this boot attempt and update. */
		retained.boots += 1;
		retained_update();

		printk("Retained data: %s\n", retained_ok ? "valid" : "INVALID");
		printk("Boot count: %u\n", retained.boots);
		printk("Off count: %u\n", retained.off_count);
		printk("Active Ticks: %" PRIu64 "\n", retained.uptime_sum);
	} else {
		printk("Retained data not supported\n");
	}

	/* Configure to generate PORT event (wakeup) on button 1 press. */
	nrf_gpio_cfg_input(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0), gpios),
			   NRF_GPIO_PIN_PULLUP);
	nrf_gpio_cfg_sense_set(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0), gpios),
			       NRF_GPIO_PIN_SENSE_LOW);

	printk("Busy-wait %u s\n", BUSY_WAIT_S);
	k_busy_wait(BUSY_WAIT_S * USEC_PER_SEC);

	printk("Busy-wait %u s with UART off\n", BUSY_WAIT_S);
	// rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
	k_busy_wait(BUSY_WAIT_S * USEC_PER_SEC);
	// rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);

	printk("Sleep %u s\n", SLEEP_S);
	k_sleep(K_SECONDS(SLEEP_S));

	printk("Sleep %u s with UART off\n", SLEEP_S);
	// rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
	k_sleep(K_SECONDS(SLEEP_S));
	// rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);

	printk("Entering system off; press BUTTON1 to restart\n");

	if (IS_ENABLED(CONFIG_APP_RETENTION)) {
		/* Update the retained state */
		retained.off_count += 1;
		retained_update();
	}

	/* Above we disabled entry to deep sleep based on duration of
	 * controlled delay.  Here we need to override that, then
	 * force entry to deep sleep on any delay.
	 */
	pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

	/* Now we need to go sleep. This will let the idle thread runs and
	 * the pm subsystem will use the forced state. To confirm that the
	 * forced state is used, lets set the same timeout used previously.
	 */
	k_sleep(K_SECONDS(SLEEP_S));

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

devzone.nordicsemi.com/.../nrf_5F00_system_5F00_off_5F00_uart_5F00_modified.hex

I have included both the code and the FW image.

Could you please provide a way to properly suspend the UART and avoid the current leakage so I can properly measure the current consumption for the System ON Idle aka System Sleep (Idle current) (no the System Off current as it is irrelevant for my application). I need to know how to properly suspend the UART this way (during runtime) as this is exactly what I need to do in my custom application ( I cannot disable it during build time using CONFIG_SERIAL=n).

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Wed, 17 Jan 2024 14:22:50 GMT

I tried the 'system OFF' sample just now and got similar results. The problem is that the sample does not suspend the UART before entering 'System OFF', causing the UART pin states to be retained during sleep. This leads to current leakage. I will report this as a bug internally. You can comment the 'rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);' at line 85 for now.

Edit: this was fixed by this commit: https://github.com/nrfconnect/sdk-zephyr/commit/2cbc452d1d0dcf9dc6bc9c6081b4bc54f6a04e89

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Wed, 17 Jan 2024 13:59:52 GMT

I used the nrf/system_off sample without any modifications. I did not set this up, it is provided with the nRF Connect SDK v2.1.0 in samples folder.

I am pasting the code of the sample below (only has two files a main.c and a retained.c which is not used as the config option for this is disabled)

main.c (FYI CONFIG_APP_RETENTION is disabled)

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

#include <stdio.h>
#include <zephyr/zephyr.h>
#include <zephyr/device.h>
#include <zephyr/init.h>
#include <zephyr/pm/pm.h>
#include <zephyr/pm/device.h>
#include <zephyr/pm/policy.h>
#include <soc.h>
#include "retained.h"
#include <hal/nrf_gpio.h>

#define BUSY_WAIT_S 2U
#define SLEEP_S 2U

/* 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_policy_state_lock_get(PM_STATE_SOFT_OFF, PM_ALL_SUBSTATES);
	return 0;
}

SYS_INIT(disable_ds_1, PRE_KERNEL_2, 0);

void main(void)
{
	int rc;
	const struct device *cons = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));

	if (!device_is_ready(cons)) {
		printk("%s: device not ready.\n", cons->name);
		return;
	}

	printk("\n%s system off demo\n", CONFIG_BOARD);

	if (IS_ENABLED(CONFIG_APP_RETENTION)) {
		bool retained_ok = retained_validate();

		/* Increment for this boot attempt and update. */
		retained.boots += 1;
		retained_update();

		printk("Retained data: %s\n", retained_ok ? "valid" : "INVALID");
		printk("Boot count: %u\n", retained.boots);
		printk("Off count: %u\n", retained.off_count);
		printk("Active Ticks: %" PRIu64 "\n", retained.uptime_sum);
	} else {
		printk("Retained data not supported\n");
	}

	/* Configure to generate PORT event (wakeup) on button 1 press. */
	nrf_gpio_cfg_input(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0), gpios),
			   NRF_GPIO_PIN_PULLUP);
	nrf_gpio_cfg_sense_set(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0), gpios),
			       NRF_GPIO_PIN_SENSE_LOW);

	printk("Busy-wait %u s\n", BUSY_WAIT_S);
	k_busy_wait(BUSY_WAIT_S * USEC_PER_SEC);

	printk("Busy-wait %u s with UART off\n", BUSY_WAIT_S);
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
	k_busy_wait(BUSY_WAIT_S * USEC_PER_SEC);
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);

	printk("Sleep %u s\n", SLEEP_S);
	k_sleep(K_SECONDS(SLEEP_S));

	printk("Sleep %u s with UART off\n", SLEEP_S);
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND);
	k_sleep(K_SECONDS(SLEEP_S));
	rc = pm_device_action_run(cons, PM_DEVICE_ACTION_RESUME);

	printk("Entering system off; press BUTTON1 to restart\n");

	if (IS_ENABLED(CONFIG_APP_RETENTION)) {
		/* Update the retained state */
		retained.off_count += 1;
		retained_update();
	}

	/* Above we disabled entry to deep sleep based on duration of
	 * controlled delay.  Here we need to override that, then
	 * force entry to deep sleep on any delay.
	 */
	pm_state_force(0u, &(struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

	/* Now we need to go sleep. This will let the idle thread runs and
	 * the pm subsystem will use the forced state. To confirm that the
	 * forced state is used, lets set the same timeout used previously.
	 */
	k_sleep(K_SECONDS(SLEEP_S));

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

This sample can be found in ..\v2.1.0\zephyr\samples\boards\nrf\system_off

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Wed, 17 Jan 2024 13:56:11 GMT

How did you turn off the UART? When UART reception is enabled in sleep mode, the HF clock remains active to allow data reception. This means the sleep current will be around .5 to 1 mA in System ON.

You can disable the UART before entering sleep using the pm_device_* APIs as shown in the code snippet I posted here: RE: How to put the UART to sleep (low power mode)

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Wed, 17 Jan 2024 13:52:03 GMT

Hi Vidar,

That is great news and very reassuring, still, I would like now that the measurement setup has been verified as correct to explain the current curves that I observe when measuring the System ON IDle (System Sleep) current curve using the unmodified nrf/system_off sample ( NCS v2.1.0 ).

With the same verified measurement setup that we confirmed in the previous message I have measured again the current consumption for the sample.

The full curve for all 5 states, of the sample, is shown below.

The state I am interested in confirming and measuring correctly is the 4th, namely the System Sleep (System ON Idle) with UART OFF, for which the current curve is shown below (zoomed in from the curve above).

more zoomed in

As you can observe the current never drops to the typical values seen in the system_on_demo.hex you sent, and they never drop below ~100uA in contrast with the system_on_demo.hex in which I get always below ~10uA. Shouldn't I get the current curve seen with system_on_demo.hex as well as the average current at least much closer than this?

I am also attaching the image used which was generated by building the nrf/system_off sample for the nRF52840DK (NCS 2.1.0) nrf_system_off_sample_v2.1.0.hex

devzone.nordicsemi.com/.../nrf_5F00_system_5F00_off_5F00_sample_5F00_v2.1.0.hex

Could you please check this with your setup as well, because it does not make sense for the average current to be 682 uA compared to the 3.59 uA measured with the system_on_demo.hex you sent me. Also the current curve never reaches below ~100uA which also does not conform to the current curve observed with the system_on_demo.hex you sent.

Thank you very much and I look forward to hearing from you.

Best regards,

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Wed, 17 Jan 2024 11:58:18 GMT

Hi Stavros,

Yes, this looks much better. Thank you for the update. The system ON measurement is slightly higher on your board, but it's still within the expected range. This can be explained by variation in sleep current from chip to chip.

Best regards,

Vidar

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Wed, 17 Jan 2024 11:45:54 GMT

Hi Vidar,

Thank you very much for your patience and support, from what I was seeing this makes sense. I desoldered the SB40. I hope the measurement setup for the nRF52840DK is now correct.

Now with the correct setup, the same as yours, with the system_on_demo.hex & system_off_demo.hex loaded. I am getting the current curves shown below. They look very similar to the ones you observed. The system_on_demo seems to be exactly the same but slightly shifted higher by about 1 uA.

system_off_demo.hex

system_on_demo.hex

Is this expected? Are these measurements normal? Am I missing something else on my setup?

Thank you and I look forward to hearing from you!

Best regards,

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Wed, 17 Jan 2024 10:58:27 GMT

Hi Stavros,

The solder bridge (SB) must be cut when measuring current. Otherwise, the nRF52840 will be powered by the USB-to-3V buck regulator when the USB is connected. Also, with the SB shorted, the PPK voltage applied on P22 may be fed into other parts of the board's circuitry, which should not be included in the measurement.

I recommend using a jumper, as it allows you to easily switch between current measuring mode and the regular mode.

Best regards,

Vidar

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Tue, 16 Jan 2024 15:04:14 GMT

Hi Vidar,

I plugged the USB to the nRF52840DK and to my PC and I get the measurement shown below

[quote userid="4240" url="~/f/nordic-q-a/106874/unexpected-consumption-using-system-off-sample-nrf52840dk/464434"]Also, have you cut the solder bridge next to P22? From your picture, it appears to be shorted with solder.[/quote]

I previously used the PPK2 in Ampere mode to measure the current so I needed to cut the SB40 (as the screenshot from the guide you posted suggests) so for this measurement I shorted it again (using solder) as the nRF52840DK would not be powered at all if I didn't, is that not correct? The nRF52840DK Guide (pg. 38) also mentions this.

Best regards,

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Tue, 16 Jan 2024 14:57:50 GMT

Hi Stavros,

I see that the USB is not connected, please try plugging it in. Also, have you cut the solder bridge next to P22? From your picture, it appears to be shorted with solder.

Best regards,

Vidar

RE: Unexpected consumption using System OFF Sample & nRF52840DK

clockis — Tue, 16 Jan 2024 14:34:54 GMT

Hi Vidar,

Thank you very much for your immediate reply!

I just loaded the system_on_demo.hex you sent to the nRF52840DK (using the nRF Connect Programmer app) & then set up the PPK2 & nRF52840DK as you mentioned ( all switches in the positions you mentioned and Supply Voltage to 3.0V as in your screenshot)

The current curve I got is shown below

which is still very different from what you are getting. What could be the reason for this?

Thank you!

Stavros

RE: Unexpected consumption using System OFF Sample & nRF52840DK

Vidar Berg — Tue, 16 Jan 2024 14:06:35 GMT

Hi Stavros,

Here's a picture of my setup:

Where the switches are put in the following positions: SW6 - nRF ONLY , SW10 - OFF , SW8 - ON , SW9 - VDD.

Please try to replicate my setup as shown above to see if you achieve better results. It's possible that your current setup is measuring more leakage. Since you are using the same hex files that I built, this should not be an issue related to the firmware configuration.

Best regards,

Vidar