battery models

[joey]

I am using the nRF54L15 with SDK 3.0.0 and developing using npm2100_fuel_gauge  for the nPM2100.

1. I see the battery model for the CR series only includes CR2032, but I am using CR2450 and CR2477. How should I select the appropriate model?

2. Should the read battery level information be saved to RRAM each time to prevent issues from system restart? After an MCU reboot, should it read the previously measured data for initialization?

3. For the nPM2100's timer, if the timer is reconfigured again before the original set period elapses, will the originally scheduled timer event be prevented from triggering?

   Thanks!

[joey]

joey said:

Moreover, I've noticed something quite puzzling.
With the same code, when using the nPM1300 power supply on the nRF54L15 PDK, the system is observed to wake up once per second and sleep the rest of the time. However, when the P6 interface on the PDK is powered by the nPM2100 (with the I²C interface disconnected), the power analyzer detects that the nRF54 wakes up every 20ms. It's unclear what the chip is doing during these wake-ups.

Power Supply Configuration Clarification:

• For nPM1300 power supply: The output of the nPM1300 on the nRF54L15 PDK is connected to the power analyzer, which then supplies power to the nRF54 for monitoring.

• For nPM2100 power supply: The nPM2100 evaluation board is connected to the power analyzer via the VDDIO and GND pins of the P11 interface on the board. then the power analyzer supplies power to the nRF54 PDK  P6  for monitoring.

  
  The power circuit configuration remains identical in both scenarios.

  The figure below shows the current consumption graph when connected to the nPM2100

 

I tested again. When connected to nPM2100, with the nRF54's UART configuration enabled,

CONFIG_LOG=y

CONFIG_SERIAL=y

CONFIG_CONSOLE=y

CONFIG_UART_CONSOLE=y

the wakeup period becomes 20ms. When the UART is disabled, there's an abnormal current spike occurring approximately every 500ms. However, this abnormal current does not appear when using nPM1300.

[Elfving]

joey said:

So, does that mean I don't need to stop and then reconfig the timer?

Well that depends on your use-case, but for the ordinary use of simply feeding the watchdog then I am rather sure that no - you do not need to reconfigure it, nor stop it. The timer won't expire.

joey said:

2、Moreover, I've noticed something quite puzzling.
With the same code, when using the nPM1300 power supply on the nRF54L15 PDK, the system is observed to wake up once per second and sleep the rest of the time. However, when the P6 interface on the PDK is powered by the nPM2100 (with the I²C interface disconnected), the power analyzer detects that the nRF54 wakes up every 20ms. It's unclear what the chip is doing during these wake-ups.

I am bit confused as to what a test like this would show. The fact that the nRF wakes up in a different frequency confirm that either the voltage to the nRF is low enough to get some sort of brownout behavior, or that there is something with the input voltage that the nRF responds to in the sw. What are you running on the nRF?

Regards,

Elfving

[joey]

Elfving said:

I am bit confused as to what a test like this would show. The fact that the nRF wakes up in a different frequency confirm that either the voltage to the nRF is low enough to get some sort of brownout behavior, or that there is something with the input voltage that the nRF responds to in the sw. What are you running on the nRF?

I  just use the demo of blinky, ncs 3.0.0

#include <stdio.h>

#include <zephyr/kernel.h>

#include <zephyr/drivers/gpio.h>

/* 1000 msec = 1 sec */

#define SLEEP_TIME_MS   10000

/* The devicetree node identifier for the "led0" alias. */

// #define LED0_NODE DT_ALIAS(led0)

/*

 * A build error on this line means your board is unsupported.

 * See the sample documentation for information on how to fix this.

 */

// static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);

int main(void)

{

    // int ret;

    // bool led_state = true;

    // if (!gpio_is_ready_dt(&led)) {

    //  return 0;

    // }

    // ret = gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE);

    // if (ret < 0) {

    //  return 0;

    // }

    while (1) {

        // ret = gpio_pin_toggle_dt(&led);

        // if (ret < 0) {

        //  return 0;

        // }

        // led_state = !led_state;

        // printf("LED state: %s\n", led_state ? "ON" : "OFF");

        k_msleep(SLEEP_TIME_MS);

    }

    return 0;

}

CONFIG_GPIO=y

CONFIG_CONSOLE=n

CONFIG_UART_CONSOLE=n

CONFIG_SERIAL=n

CONFIG_PM_DEVICE=y

CONFIG_PM_DEVICE_RUNTIME=y

 

[Elfving]

Could you check the voltage to the nRF? I am afraid this is caused by some sort of brownout behaviour

Regards,

Elfving