npm1300 zephyr driver documentation

RE: npm1300 zephyr driver documentation

cellular_iot — Tue, 15 Jul 2025 09:47:00 GMT

Just to take up this old discussion: I understand Nordic that reference designs should use as many nordic chips as possible. A demo device fully working out of the box with not much work required on customers side is worth its money in gold.
For an example my company is very successfull in LoraWAN based IoT products. Now we want to repeat this sccess with cellular-based IoT. Nordics nRF and Thingy91 seemed to be the perfect starting point as demo device, demo apps (MQTT and lwm2m_client) seemingly provide EVERYTHING we need in ecosystem, infrastructure, fuctionality and (low power) optimisatuon. That seemed to be a way better state when we devs are used to see at other vendors and we bought a handfull of devices and started developing. But it turned out that its still not enough and nRF9160 is not recommended for new products. So we bit the bullet and bought another handfull of Thingy91X - "X stands for eXtended, better, newer, greater" - as we all know. But what a bad surprise - Thingy91X is not yet suppurted as a Low Power Cellular IoT Sensor Device - its literally in the same state as the nRF9151DK. Nordic for example switched the PMIC from the well Zephyr-supported 3rd party ADP to the bad supported nPM1300. So a lot of customers and their devs hack their own incompatible nPM1300 support in order to get Thingy91X clones up and running. Now we have to decide if we go with a Thingy91 or a Thingy91X derived hardwaree design. Or we go with a hybrid - using all Thingy91 well-supprted 3rd party periperals and only go with the newer SiP. Or we just fall back to a standard modem solution. Greetings to marketing and finance that the decisition not giving the Nordic devs the time to bring nPM1300 and Thingy91X to the same level as Thingy91 will kill a lot of chips sales opportunities and drive customers to the competition.

RE: npm1300 zephyr driver documentation

Kazi Afroza Sultana — Tue, 10 Sep 2024 09:22:17 GMT

Hello,

''On a similar note, are these functions even thread-safe? I'm happy to use these drivers but only if I can trust them :D''

The drivers use the underlying I2C driver, which does have a lock (i.e. thread safe). I think a typical application might for example call the voltage regulator API from one part of the code, and perhaps the battery charger API from a different part. And that should be fine. However, there might be cases of read-modify-write patterns done by the driver which could have corner cases. For example, from reviewing the buck_set_voltage function, it seems like it might be possible to call regulator_set_voltage from separate priorities at the same time and get different results based on the order of i2c read/writes.

'' Moreover, the nPM powerUP desktop application only exports an overlay file for use in the device tree with the zephyr driver.''

Is it C code examples that is lacking here?

It would be great with feedback of missing features in NCS or PowerUP.

''However, I could not find detailed documentation of the Zephyr API's implementation of the driver, which callbacks are implemented and which ones are not etc''

We don't have this granularity of documentation. I'm not sure many of the zephyr driver implementations has it either.

There are some open sources about the npm1300 driver code locations where the various APIs are being implemented are listed here

LED driver API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/led/led_npm1300.c#L65
GPIO driver API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/gpio/gpio_npm1300.c#L195
Watchdog driver API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/watchdog/wdt_npm1300.c#L127
(voltage) Regulator API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/regulator/regulator_npm1300.c#L637
The charger is a bit tricky at the moment. The driver was written before there was a charger API, and as such it is currently implemented as a sensor device: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/sensor/nordic/npm1300_charger/npm1300_charger.c#L610

RE: npm1300 zephyr driver documentation

Achim Kraus — Mon, 02 Sep 2024 15:07:01 GMT

That's also my finding.

The question from Yaxit was, where that information, what is available and not, could be found.

RE: npm1300 zephyr driver documentation

Kazi Afroza Sultana — Mon, 02 Sep 2024 15:03:11 GMT

Hello Achim,

The led_blinkis an optional API that we have not implemented (https://github.com/nrfconnect/sdk-zephyr/blob/main/include/zephyr/drivers/led.h#L118) yet.

RE: npm1300 zephyr driver documentation

Achim Kraus — Fri, 30 Aug 2024 13:24:36 GMT

Thanks for confirming my experience.

As I wrote, usually I go straight forward to the nrf samples. That was one of the rare cases, where I started with the zephyr samples.

RE: npm1300 zephyr driver documentation

Robin M Saltnes — Fri, 30 Aug 2024 12:35:20 GMT

You are right, it looks like the nPM1300 charger driver is using the zephyr sensor API. I will forward that this is confusing to the developers of the drivers.

Update from devs: It looks like the Zephyr drvice driver api for chargers did not exist when we started developed the drivers for the nPM1300 charger, and that's why the sensor device driver API was selected.

Thanks for bringing this to my attention.

RE: npm1300 zephyr driver documentation

Achim Kraus — Fri, 30 Aug 2024 11:10:50 GMT

Using "zephyr/samples/charger" NCS 2.6.1 ?

"charger_get_prop" was always reporting an error. I think it was "-ENOTSUP" but I may have been an other error.

To be frank:

With the years I'm got used to check rather the nrf samples and there I found the "fuel_gauge", which doesn't use the "charger_get_prop" and instead uses the "sensor_channel_get". That works for me and the value reported as status are then contained in the datasheet.

RE: npm1300 zephyr driver documentation

Robin M Saltnes — Fri, 30 Aug 2024 09:32:44 GMT

To me the charger settings looks fine, what problem are you experiencing with the charger?

RE: npm1300 zephyr driver documentation

Achim Kraus — Fri, 30 Aug 2024 07:23:37 GMT

Does this apply for ncs 2.6.1 or only newer ncs?

Do you have an example of the "correct settings in the overlay"?

That's from the overlay I'm using:

    npm1300_pmic: pmic@6b {
        compatible = "nordic,npm1300";
        reg = <0x6b>;

        npm1300_gpio: gpio-controller {
            compatible = "nordic,npm1300-gpio";
            gpio-controller;
            #gpio-cells = <2>;
            ngpios = <5>;
        };

        npm1300_leds: leds {
            compatible = "nordic,npm1300-led";
            nordic,led0-mode = "error";
            nordic,led1-mode = "charging";
            nordic,led2-mode = "host";
        };

        npm1300_charger: charger {
            compatible = "nordic,npm1300-charger";
            term-microvolt = <4150000>;
            term-warm-microvolt = <4000000>;
            current-microamp = <800000>;
            dischg-limit-microamp = <1000000>;
            vbus-limit-microamp = <1000000>;
            thermistor-ohms = <10000>;
            thermistor-beta = <3380>;
            charging-enable;
        };

        npm1300_regulators: regulators {
            compatible = "nordic,npm1300-regulator";

            npm1300_buck1: BUCK1 {
                regulator-min-microvolt = <2700000>;
                regulator-max-microvolt = <3300000>;
                regulator-always-on;
            };

            npm1300_buck2: BUCK2 {
                regulator-min-microvolt = <3300000>;
                regulator-max-microvolt = <3300000>;
            };

        };
    };

RE: npm1300 zephyr driver documentation

Robin M Saltnes — Fri, 30 Aug 2024 06:37:09 GMT

fuel gauge is not the charger, The Fuel gauge sample demonstrates how to calculate the state of charge of a battery.

The nPM1300's charger uses standard Zephyr API, and can be used in any sample by using the correct settings in the overlay.

RE: npm1300 zephyr driver documentation

Achim Kraus — Thu, 29 Aug 2024 18:56:59 GMT

> but `led_blink` doesn't do anything.

You may check "zephyr/drivers/led/led_npm1300.c". Only "on" and "off" are implemented there.

RE: npm1300 zephyr driver documentation

Kazi Afroza Sultana — Thu, 29 Aug 2024 16:08:59 GMT

Hello,

I have asked the PMIC team about this issue. I will get back to you soon.

Thanks.

Kazi

RE: npm1300 zephyr driver documentation

Achim Kraus — Thu, 29 Aug 2024 07:33:31 GMT

I'm currently on the same "mission".

For the LED there is a sample:

nrf/samples/pmic/native/npm1300_one_button

and for the charger as well.

nrf/samples/pmic/native/npm1300_fuel_gauge

Not sure, why Nordic decided to not implement the charger API and used that more or less proprietary one.

I currently stuck in decoding the

sensor_channel_get(charger, SENSOR_CHAN_NPM1300_CHARGER_STATUS, &value);

for now it seems to be a rather incomplete API.