Dynamically control nPM1300 Load Switch 1 from firmware

RE: Dynamically control nPM1300 Load Switch 1 from firmware

gc0rreiab — Fri, 31 Oct 2025 18:38:20 GMT

I connected an oscilloscope to the LDSW1 output and found the issue. I had the sensor board already connected to the LDSW1 power output, and the board included a large decoupling capacitor. Because of that, when the sensor board was attached, I didn’t realize how slowly the LDSW1 was turning on and off—it gave the impression of a stable power output, since I was enabling the LDSW1 again quickly enough that the voltage level never had time to drop all the way to 0 V. That’s when I realized I needed to enable the active-discharge property on my LD1 regulator:

/* Load switches */
npm1300_ek_ldo1: LDO1 {
    status = "okay";
    regulator-min-microvolt = <1000000>;
    regulator-max-microvolt = <3300000>;
    regulator-initial-mode = <NPM13XX_LDSW_MODE_LDSW>;
    active-discharge;
};

Once I did that, I started seeing the power turn on/off much faster. Thanks for your help!

Now I’m facing another issue: I have an SHT4x sensor powered by the LDSW1. At boot time, the SHT4x isn’t powered yet because it’s behind the LDSW1 load switch, which is controlled by the PMIC. During system boot, Zephyr automatically tries to probe the SHT4x as part of its device initialization sequence—this happens before main(). Since the sensor isn’t powered yet, the I²C transactions fail (no ACK from the SHT4x), causing the init function to return a negative value. As a result, Zephyr marks the device as unready:

device->state->initialized = false;

Later in the application, when calling:

device_is_ready(sht_dev)

It returns false because the initialization previously failed.

What’s the recommended way to handle this kind of situation, where a sensor is powered on by the PMIC only after the boot sequence?

I wasn’t sure whether it was best to continue discussing this issue in the same ticket, since the problem—although related to the nPM1300 and Load Switch 1—is quite different. Therefore, I opened a new ticket for it.

RE: Dynamically control nPM1300 Load Switch 1 from firmware

SergeiOv — Fri, 31 Oct 2025 11:48:01 GMT

Just tried your code without any modifications (only added `bias-pull-up` to the i2c pins configuration and commented out the sensor code since I don't have it) on 2.8, and I get the expected behavior again...

If you have a logic analyzer, do you think you could examine the I2C lines during your code execution? You should see the writes as on the screenshot above. You will of course have more due to the sensor communication, but these are responsible for enabling and disabling the LDSW1 respectively.

RE: Dynamically control nPM1300 Load Switch 1 from firmware

gc0rreiab — Wed, 29 Oct 2025 15:35:20 GMT

Thanks for getting back to me! I’m using nRF Connect SDK 2.8 — both the SDK and toolchain are version 2.8. Could you try to reproduce my setup using NCS 2.8 and see if it works on your end?

RE: Dynamically control nPM1300 Load Switch 1 from firmware

SergeiOv — Wed, 29 Oct 2025 12:49:28 GMT

I don't see a reason why LDSW wouldn't disable in your situation.

What version of NCS/Zephyr is this? I tried your code with latest Zephyr (with minor adjustments due to some API changes) just now, and this behaves as expected. Maybe there was a bug in an earlier version, so I can try whichever version you're developing with.

One thing I could think of is the fact that according to Zephyr documentation, the `regulator_enable` function is a "Reference-counted request" (https://docs.zephyrproject.org/apidoc/latest/group__regulator__interface.html#ga06e3109b9607521fe07686c6d601e460). This means that if this function is called twice in a row, in order to disable said regulator one would need to call the disable function twice as well. So, maybe this somehow plays a role here, although I see that you check `regulator_is_enabled` each time before enabling or disabling it, so it shouldn't really happen...