i am currently working on a board that is using the nrf54l15 chip. and when CONFIG_BT=n or just not included in the prj.conf i see a power consumption of about 80uA on the entire circuit, but when i set the value to Y, it jumps to 344uA. and i am trying to figure out why this is happening. anybody have any ideas?
Hi,
I am not able to explain why just enabling CONFIG_BT=y increases current consumptoin if you do not use BT. At the same time, enabling Bluetooth whould not increase the current consumption signficantly before you start to use id (advertise/scan/connect).
How do you measure the current consumptoin? Is the numbers you wrote idle current consumption or average over some time? Do you have other components that draw current, such as logging? If so, disable UART logging.
But again, having BT just enabed in Kconfig should not matter much so I think we need to look more closely at your applcation.
hello,
yeah this was measured using an OTii and in both cases this is an average value over time.
the code is very simple, i made a main to talk to our LTC337 and put it in low power mode, i also disabled uart logging and uart rx, and after all that i see teh 80uA, but as soon as set CONFIG_BT=y it jumps, and nothing is calling the BLE stack.
LOG_MODULE_REGISTER(main, LOG_LEVEL_INF);
#define LTC3337_NODE DT_ALIAS(power_monitor)
#define LTC3337_I2C_BUS DEVICE_DT_GET(DT_BUS(LTC3337_NODE))
static const struct device *const ltc3337_i2c_bus = LTC3337_I2C_BUS;
static void suspend_ltc3337_i2c_bus(void)
{
int ret;
if (!device_is_ready(ltc3337_i2c_bus))
{
LOG_ERR("LTC3337 I2C bus is not ready");
return;
}
ret = pm_device_action_run(ltc3337_i2c_bus, PM_DEVICE_ACTION_SUSPEND);
if (ret != 0)
{
LOG_WRN("Failed to suspend LTC3337 I2C bus: %d", ret);
}
else
{
LOG_INF("LTC3337 I2C bus suspended");
}
}
static void configure_ltc3337_for_lowest_current(void)
{
struct power_monitor_config cfg = {0};
uint16_t status = 0;
uint16_t accumulated_charge = 0;
int32_t die_temp_mc = 0;
int ret;
LOG_INF("Starting LTC3337 low-power test");
if (!power_monitor_is_ready())
{
LOG_ERR("Power monitor backend is not ready");
return;
}
LOG_INF("Power monitor backend is ready");
ret = power_monitor_get_status(&status);
if (ret != 0)
{
LOG_ERR("Failed to read LTC3337 status: %d", ret);
}
else
{
LOG_INF("LTC3337 status REG_C: 0x%04x", status);
}
ret = power_monitor_get_accumulated_charge(&accumulated_charge);
if (ret != 0)
{
LOG_ERR("Failed to read LTC3337 accumulated charge: %d", ret);
}
else
{
LOG_INF("LTC3337 accumulated charge REG_B: 0x%04x", accumulated_charge);
}
ret = power_monitor_get_die_temp_mc(&die_temp_mc);
if (ret != 0)
{
LOG_ERR("Failed to read LTC3337 die temp: %d", ret);
}
else
{
LOG_INF("LTC3337 die temp: %d.%03d C",
die_temp_mc / 1000,
die_temp_mc < 0 ? -(die_temp_mc % 1000) : die_temp_mc % 1000);
}
/*
* Lowest LTC3337 chip-current test mode.
*
* counter_shutdown = true shuts down the coulomb counter/current source.
* For real coulomb-counting sleep, set this to false.
*/
cfg.prescaler = 0;
cfg.clear_interrupt = false;
cfg.counter_check = false;
cfg.counter_shutdown = true;
cfg.adc_conv_start = false;
cfg.alarm_level = 0xFF;
ret = power_monitor_set_config(&cfg);
if (ret != 0)
{
LOG_ERR("Failed to configure LTC3337 low-power mode: %d", ret);
}
else
{
LOG_INF("LTC3337 configured for lowest-current test mode");
}
}
int main(void)
{
configure_ltc3337_for_lowest_current();
/*
* Give deferred logger time to flush before suspending I2C and sleeping.
*/
LOG_INF("Waiting for logs to flush before entering sleep");
k_sleep(K_SECONDS(2));
suspend_ltc3337_i2c_bus();
int ret;
LOG_INF("Entering low-power sleep");
k_sleep(K_SECONDS(1));
while (1)
{
k_sleep(K_FOREVER);
}
}
Hi, I see. That is unexpected, I am not able to understand how that config makes a big inpact on an application when Bluetooth is not enabled. A few more questions in order to narrow it down:
if BOARD_CUSTOM_BOARD_NRF54L15_CPUAPP config HAS_BT_CTLR default BT config ROM_START_OFFSET default 0 if PARTITION_MANAGER_ENABLED default 0x800 if BOOTLOADER_MCUBOOT config BOARD_ENABLE_DCDC bool "DCDC mode" select SOC_NRF54L_VREG_MAIN_DCDC default y endif # BOARD_CUSTOM_BOARD_NRF54L15_CPUAPP if BOARD_CUSTOM_BOARD_NRF54L15_CPUAPP_NS config HAS_BT_CTLR default BT # By default, if we build for a Non-Secure version of the board, # enable building with TF-M as the Secure Execution Environment. config BUILD_WITH_TFM default y if BOARD_CUSTOM_BOARD_NRF54L15_CPUAPP_NS # By default, if we build with TF-M, instruct build system to # flash the combined TF-M (Secure) & Zephyr (Non Secure) image config TFM_FLASH_MERGED_BINARY default y depends on BUILD_WITH_TFM # TODO: Remove the options below when (NCSDK-25023) is done config NRF_SPU_FLASH_REGION_SIZE hex default 0x4000 # This option does not apply to 54, but we pretend the HW has this limitation # for now for easier porting. NCSDK-25023 help FLASH region size for the NRF_SPU peripheral. For nrf54 the region size is configurable per-region so this option does not apply. config NRF_SPU_FLASH_REGION_ALIGNMENT hex default 0x4000 # This option does not apply to 54, but we pretend the HW has this limitation # for now for easier porting. NCSDK-25023 help FLASH region size for the NRF_SPU peripheral. For nrf54 the region size is configurable per-region so this option does not apply. config NRF_SPU_RAM_REGION_SIZE hex default 0x2000 # This HW limitation does not apply to 54, but we pretend # it does for now for easier porting. NCSDK-25023 help RAM region size for the NRF_SPU peripheral. For nrf54 the region size is configurable per-region so this option does not apply. config NRF_SPU_RAM_REGION_ALIGNMENT hex default 0x1000 help RAM regions must be aligned to this value due to SPU HW limitations. endif # BOARD_CUSTOM_BOARD_NRF54L15_CPUAPP_NS
the only other file i have that relies on BT is this config. I would need to get permission to see if i can give details about the hardware.
Hi,
I missed this before, but I believe you may bee seeing the issue fixed here. This will be fixed in future SDK releaes, but for older releaes you can cherry pick this commit.
Hi,
I missed this before, but I believe you may bee seeing the issue fixed here. This will be fixed in future SDK releaes, but for older releaes you can cherry pick this commit.