nPM1300 Configuration

RE: nPM1300 Configuration

levijo — Tue, 22 Apr 2025 12:52:42 GMT

Not really, at list in the meanwhile.

What is strange, is that immediately after the device_is_ready, there are 1 or more api function that uses I2C and works fine, without any failures. so ironically removing this function solved it, and the frequent failures we had disappeared.

While I would love to analyze and debug it farther, for now this solution satisfies us, and I'm forced to focus on other burning issues.

Did anyone report on similar issues before? Can upgrading to ncs 2.9.0 fix this issue?

RE: nPM1300 Configuration

Edvin — Tue, 22 Apr 2025 12:45:02 GMT

The device_is_ready function does communicate via I2C. So if it fails, then there is reason to believe that it may fail at a later point.

If you were able to reproduce it on a DK, then I could reproduce it here on my desk, or even forward it to our PMIC team, which could analyze it.

[quote user="levijo"]

We have the same issue with the IMU driver as well but much less often than the fuelgague.

[/quote]

That could be related. Perhaps some collission/HW issues.

So while the device_is_ready() is not strictly needed, the fact that it sometimes returns an error indicates that something is not correct. Do you see any other issues with the PMIC? Some bad/weird battery measurements?

Best regards,

Edvin

RE: nPM1300 Configuration

levijo — Sun, 20 Apr 2025 15:34:40 GMT

I'm using a PCB where it is more difficult to analyze I2C wires.

Does device_is_ready function communicate with the device via i2c to verify the device communication? to my understanding it does not, so I don't see how this is related.

using the DK is not possible as we don't have those peripherals connected.

RE: nPM1300 Configuration

Edvin — Mon, 14 Apr 2025 10:14:57 GMT

Hello,

[quote user="levijo"]so, the part that is failing is device_is_ready(fuelgauge_device) function returns sometimes false. statistically its one out a few resets process. Unfortunately, this happens although the device is ready, and removing this check solves the problem. We have the same issue with the IMU driver as well but much less often than the fuelgague.[/quote]

So sometimes the device_is_ready() fails, and sometimes there are issues with the IMU driver.

Can you please try to attach a logic analyzert to your nPM I2C GPIOs, and check if the behavior changes when it succeeds and when it doesn't?

Are you using a DK and an nPM evaluation kit? Or do you have a PCB where it is difficult to analyse the I2C wires?

Are you able to reproduce the issue on an nRF5340DK and an nPM1300 Evaluation kit? If so, is it possible to upload an application that can reproduce the issue that you are seeing?

Best regards,

Edvin

RE: nPM1300 Configuration

levijo — Sat, 12 Apr 2025 14:23:06 GMT

Hi Edvin,

so, the part that is failing is device_is_ready(fuelgauge_device) function returns sometimes false. statistically its one out a few resets process. Unfortunately, this happens although the device is ready, and removing this check solves the problem. We have the same issue with the IMU driver as well but much less often than the fuelgague.

So, I'm wondering, is this check redundant? what is good for? should I remove this check for all of the drivers (we have quite a few of those checks)?

RE: nPM1300 Configuration

Edvin — Thu, 10 Apr 2025 13:06:06 GMT

Are you able to see what part of this function that returns an error? Perhaps if you assign different return values for the different checks (for debugging purposes), and print the return value after the hal_fg_init() has returned? Which check is it that fails?

Best regards,

Edvin

RE: nPM1300 Configuration

levijo — Tue, 08 Apr 2025 15:30:35 GMT

Thank Edvin, this seems to work well!

I have another issue related to the npm1300 driver. occasionally this function - hal_fg_init() returns false.

Is there a problem in this function? I also tried a retry mechanism on this function, but when it fails, it always fail until the next reboot.

int hal_fg_init(void)
{
    struct sensor_value value;
    struct nrf_fuel_gauge_init_parameters parameters = {
        .model = &battery_model,
        .opt_params = NULL,
    };
    int32_t chg_status;
    bool found = false;

    if (fuelgauge_device != NULL) {
        LOG_INF("fuel gauge HAL already initialized");
        return 0;
    }

    LOG_INF("initialize NPM1300 fuel gauge HAL (version: \"%s\", battery: \"%s\")",
            nrf_fuel_gauge_version, battery_model.name);

    fuelgauge_device = DEVICE_DT_GET(FUELGAUGE_CONTROLLER0_NODE);
    if (fuelgauge_device) {
        if (device_is_ready(fuelgauge_device)) {
            LOG_INF("found fuel gauge controller \"%s\"", fuelgauge_device->name);
            found = true;
        } else {
            LOG_ERR("Fuel gauge controller \"%s\" is not ready", fuelgauge_device->name);
        }
    }

    if (found == false) {
        LOG_ERR("no fuel gauge controller found");
        return -1;
    }

    if (read_npm1300_fuelgauge(fuelgauge_device, &parameters.v0, &parameters.i0, &parameters.t0,
                               &chg_status) < 0) {
        return -1;
    }

    /* Store charge nominal and termination current, needed for ttf calculation */
    sensor_channel_get(fuelgauge_device, SENSOR_CHAN_GAUGE_DESIRED_CHARGING_CURRENT, &value);
    max_charge_current = (float)value.val1 + ((float)value.val2 / 1000000);
    term_charge_current = max_charge_current / 10.f;

    nrf_fuel_gauge_init(&parameters, NULL);

    ref_time = k_uptime_get();

    if (configure_npm1300_events() < 0) {
        return -1;
    }

    return 0;
}

RE: nPM1300 Configuration

Edvin — Mon, 07 Apr 2025 13:12:39 GMT

Our PMIC team commented on the discharge limit was a bit high. Try setting it to 240mA.

Best regards,

Edvin

RE: nPM1300 Configuration

levijo — Sun, 06 Apr 2025 06:24:25 GMT

thanks I will try it and see if this works.

regarding the first question I asked, about the correct battery configuration settings, I used chatGPT to help me with that.

can you review it here and let me know if its OK? It would be helpful to have a professional set of eyes to approve it:

chatgpt.com/.../67f21a09-60ec-8001-95c5-2149c9cc0a10

RE: nPM1300 Configuration

Edvin — Fri, 04 Apr 2025 13:11:55 GMT

Hello,

Sorry for the late reply!

There were some issues detecting the VBUS status register in some NCS versions, and I believe this was present on v2.7.0.

I suggest that on startup, you check the register directly, and then use the events to be notified on changes on the USB connection.

You can read the register using this snippet:

https://github.com/nrfconnect/sdk-zephyr/blob/v3.6.99-ncs2/drivers/sensor/nordic/npm1300_charger/npm1300_charger.c#L301

ret = mfd_npm1300_reg_read(config->mfd, VBUS_BASE, VBUS_OFFSET_STATUS, &data->vbus_stat);

Alternatively, you can read it more directly like it is done here:

https://github.com/nrfconnect/sdk-nrf/blob/v2.7.0/samples/pmic/native/npm1300_one_button/src/main.c#L64-L72

	if (pins & BIT(NPM1300_EVENT_VBUS_DETECTED)) {
		printk("Vbus connected\n");
		vbus_connected = true;
	}

	if (pins & BIT(NPM1300_EVENT_VBUS_REMOVED)) {
		printk("Vbus removed\n");
		vbus_connected = false;
	}

Best regards,

Edvin

RE: nPM1300 Configuration

levijo — Thu, 27 Mar 2025 06:53:25 GMT

we are using NCS version 2.7.0.

this function is called in boot and returns the usb connection status on init:

int battery_init(void)
{
    if (hal_fg_init() != 0) {
        LOG_ERR("failed to initialize fuel gauge HAL");
        return -1;
    } else {
        hal_fg_register_events_cb(charger_event_cb);
    }
    battery_info.flags.is_charger_connected = 0;
    battery_info.flags.is_full = 0;
    battery_info.flags.is_critical_level = 0;
    battery_info.flags.is_low_level = 0;
    battery_info.flags.unused = 0;

    if(battery_update_info() < 0) {
        return -1;
    }
    if(hal_fg_charger_connected()) {
        battery_info.flags.is_charger_connected = 1;
    }
    return 0;
}

bool hal_fg_charger_connected(void)
{
    struct sensor_value val;
    bool connected;
    int ret;

    ret = sensor_attr_get(fuelgauge_device, SENSOR_CHAN_CURRENT, SENSOR_ATTR_UPPER_THRESH, &val);
    if (ret < 0) {
        LOG_ERR("failed to read npm1300 current");
        return false;
    }

    connected = (val.val1 != 0) || (val.val2 != 0);

    if (!connected) {
        /* the SENSOR_CHAN_CURRENT attr is not working properly so this code is needed.
         remove when npm1300 charger driver fix this issue. */
        float avg_current_mA;

        ret = hal_fg_get_data(NULL, &avg_current_mA, NULL, NULL);
        if (ret < 0) {
            return false;
        }
        connected = (avg_current_mA < 0);
    }

    return connected;
}

RE: nPM1300 Configuration

Edvin — Wed, 26 Mar 2025 21:59:09 GMT

Hello,

From the first glance, the disttcharge limit (1.34 A) seems too high for such a small battery. The battery datasheet recommends to stay within 1C (240mA) or 2C bursts/non-continuous (480mA).

As for the USB detection issue, it is difficult to say without more information. First, what NCS version are you using? For a while we had some issues properly exposing the VBUS status register via the charger API, and the USB detection relied on interrupts.

Do you have any code snippets and logs to share, so that we can look into this? Particularly related to the start of the application, where the 0% value comes from.

Best regards,

Edvin