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!

[Elfving]

CR2450

You can use the CR2032 model. It is based on the same chemistry and has essentially the same discharge curve

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?

Ideally yes, for best accuracy over time. Then it will start from correct level at startup and won't take long time to converge to the actual state of the battery. For more details see here.

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?

About #3 you can stop the timer with TASKS_STOP and then reconfigure it before activating it again. The originally configured timer won't trigger then.

Regards,

[joey]

Elfving said:

About #3 you can stop the timer with TASKS_STOP and then reconfigure it before activating it again. The originally configured timer won't trigger then.

HI

I called the mfd_npm2100_set_timerand mfd_npm2100_start_timerfunctions of the mfd_npm2100.c  to run the timer, but found that there is no function to stop it. Do I need to add this stopping function myself? (NCS 3.0.0 SDK)

and what is the function of 'watchdog_kick' in the register，(7.2.6.3  , npm2100 datasheet)？

[Elfving]

joey said:

and what is the function of 'watchdog_kick' in the register，(7.2.6.3  , npm2100 datasheet)？

I believe it is the same as feeding it. The nPM just uses a different word. Apparently "patting" is also commonly used.

joey said:

I called the mfd_npm2100_set_timerand mfd_npm2100_start_timerfunctions of the mfd_npm2100.c  to run the timer, but found that there is no function to stop it. Do I need to add this stopping function myself? (NCS 3.0.0 SDK)

Yeah a stop function doesn't seem to be here. You can write one yourself using TASKS_STOP, or alternatively use the hibernate function, depending on your use-case. 

Regards,

Elfving

[joey]

Elfving said:

I believe it is the same as feeding it. The nPM just uses a different word. Apparently "patting" is also commonly used.

1、So, does that mean I don't need to stop and then reconfig the timer? Instead, I can directly set this register to 1 to achieve the watchdog feeding effect, and the previous timer won't expire?

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.

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

 

[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