Unexpected consumption using System OFF Sample & nRF52840DK

[clockis]

Greetings,

I have been measuring the current consumption of our custom FW in our custom board using PPK2 and found some unexpected spikes in the current consumption curve.

I decided to look deeper into this so programmed our custom FW to the nRF52840 DK and the behavior remained the same.

Finally I decide to test some samples with absolutely no changes on the nRF52840DK to confirm the normal behavior of the current curves I should see when the system is Active, in Sleep (system ON Idle) & finally System OFF(which is irrelevant for my application).

It seems that flashing the nRF System OFF sample (unchanged, as it was in the NCS) to the nRF52840 DK produces the same current curve. As mentioned in other tickets ( I have searched and read all of the relevant ones in existence) the current curve in System Sleep (with UART off) should be a few tens of microamps but I am consistently getting the current curve shown below.

Connection diagram (PPK2 in Ampere mode) 
I have also measured with the SW6 to the DEFAULT and nRF ONLY positions but the results were the same.

!!!Below you can see the current curve for the nRF52840DK flashed with the nRF System OFF sample and focus on the duration that corresponds to the System Sleep (System ON Idle) part of the duration ( the sample enters the SYstem Sleep state for two seconds, this what is shown below)

System Sleep (System ON Idle)

System Sleep (System ON Idle) the curve shown above ZOOMED IN ( to be able to distinguish the spikes)

The whole current curve for the System OFF sample

I have tried all different methods of measurement using the PPK2 (Ampere mode & Source mode by providing the external supply from the PPK2) but in all instances, I am getting the same current curve(shown above).

I have also tried the beacon sample (with no changes/modification, as is) and gotten the same curve in Idle mode (apart from when the device wakes up to advertise), between the advertising events I get the same spikes up to 3mA with the current never falling bellow 100's of microamps.

Beacon sample

Beacon sample ZOOMED IN

Even more ZOOMED IN

According to other tickets as well as this one that contains current curves for the Beacon sample this is not at all the Normal curve I should see for this sample

(this is what the people in the ticket mentioned report as the normal current curves for this sample)

which is completely different from my curves.

What could be the cause for the behavior and current curves I am observing when loading the nRF System OFF & Beacon samples to the nRF52840DK and measuring using the PPK2?

Please get back to me for any further information needed, I can also provide the data for the curves shown above.

I look forward to hearing from you.

Best regards,

Stavros

[runsiv]

Hi Stravos 

We are about to enter Christmas vacation on support, so the support will be slow/limted until start of January. 
Just to verify. Is the DK prepared for current measurement as it is described in the Current measurement guide?

I would also recommend to not power the DK over USB when you do current measurement as it might affect the measurement. 

Regards

Runar

[clockis]

Hi runsiv,

A kind reminder, for any updates or information about this would be very helpful as this is a critical issue for us.

I look forward to hearing from you.

Best regards,

Stavros

[Vidar Berg]

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";
};

[clockis]

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

[Vidar Berg]

Hi Stavros,

Glad to hear that it worked now.

clockis said:

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?

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

[clockis]

Vidar Berg said:

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

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

BR

Stavros

[Vidar Berg]

Hi Stavros,

clockis said:

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

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?

clockis said:

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.

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

[clockis]

Hi Vidar,

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

Vidar Berg said:

You also mention having some sensors, are they included in the measurement or powered separately?

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.

Vidar Berg said:

Have you tried to not enabling these sensors?

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

[clockis]

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.

[clockis]

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?

[Vidar Berg]

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.

[clockis]

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?