nRF9151 + nPM1300: PMIC not powering up reliably (sometimes not ready / charger / fuel gauge init fails)

Hello Nordic Team,

We have developed a custom PCB using nRF9151 and nPM1300.
Sometimes, the PMIC powers up and works normally; other times it doesn’t start at all.
It occasionally works only when connected to a debugger via SWD (SDIO, SCLK, RESET).

Hardware Configuration

  • Battery: 3.7 V Li-Po (600 mAh)

  • PMIC Connections:

    • VSYS → nRF9151 VDD

    • BUCK1 (1.8 V) → nRF9151 GPIO (VDD_GPIO) + I²C pull-ups

    • BUCK2 (3.3 V) → other modules

    • LDO1/LDO2 → additional 1.8 V + RTC supply

  • I²C Pull-ups: 4.7 kΩ to 1.8 V (BUCK1 output)

Issue Summary

  • Sometimes PMIC powers the system normally.

  • Sometimes it does not start from battery.

  • When connected via nRF Connect / Debugger, PMIC initializes correctly (BUCK1/2 + LDOs output voltages).

  • When running standalone (battery only), PMIC occasionally fails to power up.

  • Software logs:

    • “PMIC device not ready”

    • “Charger not ready”

    • “Fuel gauge init failed”
      (These failures occur randomly on cold boot.)

Question

Do we need a specific power-up sequence between nRF9151 and nPM1300?
Any known conditions or timing dependencies that could cause the PMIC not to start properly?


k_msleep(1000);

if (!device_is_ready(pmic)) {
    printk("PMIC device not ready.\n");
    return -1;
}
if (!device_is_ready(charger)) {
    printk("Charger device not ready.\n");
    return -1;
}

if (fuel_gauge_init(charger) < 0) {
    printk("Could not initialize fuel gauge.\n");
    return -1;
}

regulator_enable(buck1);
regulator_enable(buck2);
regulator_enable(ldo1);
regulator_enable(ldo2);


&i2c2 {
    status = "okay";
};

#include <dt-bindings/regulator/npm1300.h>

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

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

            npm1300_ek_buck1: BUCK1 {
                regulator-init-microvolt = <1800000>;
            };

            npm1300_ek_buck2: BUCK2 {
                regulator-init-microvolt = <3300000>;
                /delete-property/ enable-gpios;
            };

            npm1300_ek_ldo1: LDO1 {
                regulator-init-microvolt = <1800000>;
                regulator-initial-mode = <NPM1300_LDSW_MODE_LDSW>;
            };

            npm1300_ek_ldo2: LDO2 {
                regulator-init-microvolt = <1800000>;
                regulator-initial-mode = <NPM1300_LDSW_MODE_LDSW>;
            };
        };

        npm1300_ek_charger: charger {
            compatible = "nordic,npm1300-charger";
            term-microvolt = <3600000>;
            current-microamp = <150000>;
            charging-enable;
        };
    };
};


Sometimes the above sequence fails at different steps (PMIC / Charger / Fuel gauge), though it works fine once in a while.

Observation

When debugger is attached, I²C communication and PMIC initialization always succeed — which suggests possible startup timing, reset synchronization, or power-rail sequencing issue between nRF9151 and nPM1300.

Could you please guide us on:

  • Correct power-up timing or initialization order?

  • Any recommended delay or condition to check before I²C access?

  • Whether PMIC requires an external enable or wake sequence from nRF9151?

Parents
  • Hello,

    What is the voltage on VSYS/buck outputs in the case when startup has failed? Oscilloscope plot of VBAT, VSYS, buck outputs at startup would help us investigate this further. 

    Thanks.

  • Hello,

    We measured the rails at startup and observed the following steady-state values:

    • VBAT = 3.7 V

    • VSYS = 3.7 V

    • VIN = 1.5 V

    • BUCK1 = 1.8 V (default) → measured 2.5 V 

    • BUCK2 = 3.3 V (default) → measured 3.3 V

    Notes:

    • When both BUCK1 and BUCK2 are configured to 1.8 V, the system works correctly.

    • When BUCK1 is set to 1.8 V and BUCK2 to 3.3 V, BUCK2 measures 3.3 V but BUCK1 rises to ~2.5 V instead of 1.8 V.

      We observed another important point during testing:

      • When a load is connected to BUCK2, the PMIC starts and works normally.

      • When there is no load on BUCK2, the PMIC does not start properly.

      It seems that the PMIC startup is dependent on the presence of a load on BUCK2.



              

  • Hello, 

    It sounds like there is something backfeeding the BUCK1 output voltage. It can be leakage between different power domains through ESD diode on IO pin for example. Anyway in hysteretic mode the buck converter cannot sink current, so if there is leakage from other rail to the buck output, the voltage will rise. So what I would suggest is going through the different power domains and making sure all IOs etc are supplied and referenced to the correct level. 

    You mentioned adding a load to the buck2 effects the behavior someway. Is that in regard to the buck output voltages or something else? How much load did you add? What does the PMIC does not start properly mean? Do you have a oscilloscope plot or something to show this behavior?

Reply
  • Hello, 

    It sounds like there is something backfeeding the BUCK1 output voltage. It can be leakage between different power domains through ESD diode on IO pin for example. Anyway in hysteretic mode the buck converter cannot sink current, so if there is leakage from other rail to the buck output, the voltage will rise. So what I would suggest is going through the different power domains and making sure all IOs etc are supplied and referenced to the correct level. 

    You mentioned adding a load to the buck2 effects the behavior someway. Is that in regard to the buck output voltages or something else? How much load did you add? What does the PMIC does not start properly mean? Do you have a oscilloscope plot or something to show this behavior?

Children
  • Hello Nordic Team,

    We are using nRF9151 with nPM1300 PMIC and some other peripheral devices in our custom design.

    We have observed an issue with LDO1 on the nPM1300.
    When we power the system from a battery (connect or disconnect the battery), sometimes LDO1 does not start properly — instead of 1.8 V, we see random voltages between 300 mV to 700 mV.

  • Hello,

    Since LDO1 is turned on with software, it can be caused by TWI command not going through. The 300mV level would indicate the LDO did not start. Since there is something already leaking between the voltage domains, this can effect the IO levels and the communication. 

  • Hello Team,

    We are developing an IoT system using nRF9151, SiWG917Y Wi-Fi module, and nPM1300 PMIC.
    The nPM1300 supplies multiple rails as follows:

    • BUCK1 (1.8V) → nRF9151 GPIO + MAX30001 ECG

    • BUCK2 (3.3V) → SiWG917Y Wi-Fi module

    • LDO1 (1.8V) → RTC

    • LDO2 (1.8V) → Accelerometer (LIS2DW12) + NAND Flash

    Issue 1:
    When powered from battery only, all rails normally start at the correct voltages.
    However, in some cases (around 2 out of 10 power cycles), LDO1 outputs a random voltage between 0.4V–0.7V, while other rails remain stable.

    Issue 2:
    When connecting USB to charge the battery, BUCK1 output rises to ~2.5V instead of 1.8V.
    This issue occurs only when USB is connected.

    We’ve verified the schematic (attached above) and decoupling as per datasheet, but these issues persist.
    Looking for suggestions on possible root causes or recommended checks related to power sequencing, VSET configuration, or VBUS/VBAT interaction in nPM1300.

    Thanks,

  • Hello,

    Can you send out a oscilloscope plot of the startup showing: 

    - Buck1, Buck2, VSYS, LDO1, LDO2 voltages

    - TWI communication

    For investigating where the leakage between different power rails come from you would have to work ruling out possible leakage paths on the board one by one until you would find the culprit. We are not experts on SiLabs SoC, so it is difficult to comment on that part of the schematic.

Related