nPM1300 BUCK2 not regulating to 3.3 V in standalone mode

[tarunkt]

Hi Nordic team,

I'm debugging a custom board using the nPM1300 and I'm seeing unexpected behavior from BUCK2. I'd appreciate any guidance on whether I'm misunderstanding the VSET configuration or if there is another startup/configuration requirement that I'm missing.

Hardware Configuration

• PMIC: nPM1300

• Operating mode: Standalone (no PMIC configuration over I²C)

• BUCK2 desired output: 3.3 V

• VSET2 resistor: 300 kΩ to GND

• According to the nPM1300 Product Specification v1.3, the VSET2 table shows:

  • 250–500 kΩ → 3.3 V

• NTC pin connected to GND through a 0 Ω resistor

• No intentional connection between BUCK2 output and VSYS

• Resistance from VSET2 to GND measures approximately 300 kΩ on the board

Observed Behavior (Board Under Test)

With USB power connected:

Signal	Measured Voltage
VBUS	5.1 V
VSYS	5.0 V
BUCK2 Output (VOUT2)	4.45 V

The expected BUCK2 output is 3.3 V, but instead it sits around 4.45 V.

Battery-only operation

When running from battery:

• One board measures ~3.3 V at BUCK2 output

• Another board measures ~3.5 V at BUCK2 output

The output appears to track the battery voltage rather than regulate to a fixed 3.3 V.

Questions

1. Is 300 kΩ a valid VSET2 value for selecting 3.3 V on nPM1300 Product Specification v1.3?

2. In standalone mode, should BUCK2 automatically enable and regulate to the VSET-selected voltage at startup?

3. Could grounding the NTC pin through 0 Ω affect BUCK2 startup or operation?

4. Is it expected that VSYS measures almost the same as VBUS (5.0 V vs 5.1 V) in this configuration?

5. Are there any recommended measurements or status registers that would help determine whether BUCK2 is actually enabled?

Any suggestions for further debugging would be greatly appreciated.

Thank you.

[Szabolcs]

Hi,

This sound like an issue, the nPM should start the Buck automatically with the configuration you stated. Can you please post your schematic?

Regarding your questions:

1. Yes,
2. Yes.
3. I think it shouldn't, but you can try replacing it with a 10K resistor just for debugging purposes. If there is no NTC for the battery, this feature should be disabled in the register, but I think it only affects battery charging, and not the Bucks.
4. Yes, there is no regulator behind VSYS, it is only a current-limited output.
5. Yes, see BUCKSTATUS and BUCK2VOUTSTATUS.

[tarunkt]

Dear Szabolcs,

Thank you for your response and for clarifying the questions.

Please find the complete schematic attached to this ticket for your review.

https://devzone.nordicsemi.com/support/359762

Kindly review the schematic and let me know if you notice anything that could prevent BUCK2 from starting or regulating correctly?

Thank you for your support.

Regards,

Tarun

[tarunkt]

Additional information from testing:

I am able to communicate with the nPM1300 successfully over I²C.

Using the regulator shell commands, I can query the PMIC and obtain the following:

regulator vget BUCK1
3.300000 V

regulator vget BUCK2
3.300000 V

So there appears to be a discrepancy between the PMIC-reported BUCK2 voltage setting (3.3 V) and the physical voltage measured on the BUCK2 output (3.33 V) when LiPo Battery only connected state.

Then I connected USB to give the VBUS supply when battery connected, immediately the voltage on VBUCK2 changed to 4.2V. Still I could see the I2C communication active.

Current consumption shows: 90-110mA in the USB power-meter

Please let me know any insights.

Thank you

[tarunkt]

Queries:

• Any OTP/factory-programmed settings exist.
• Any retained configuration can override VSET startup behavior.

[Szabolcs]

Hi,

thank you for the extra information. I see that you have the designed reviewed, I double checked it just in case, but it is OK, I don't see any obvious issues that could cause this.

The nPM reporting 3.3V makes sense, as this is the maximum voltage for the Bucks, so anything higher is probably over the measurement limit.

There is no OTP or retained registers in the nPM, I think it does not have any memory at all, so a reset should always bring it to the same state.

The current consumption is suspiciously high. The default current limit is 100 mA, so the nPM is probably in current limiting mode. Could you double check your board for short circuits, soldering issues, etc.? (I see in your other ticket that you needed rework.)

Do all of your board have the rework? Do all of them produce the same symptoms?

Can you make oscilloscope measurements? Seeing VBUS, VSYS, and the buck output and SW lines on startup would be helpful.

[tarunkt]

Dear Szabolcs,

Thank you for reviewing the schematic and for your feedback.

Regarding the current consumption, I would like to clarify that the measured current on the boards under test is approximately 30 - 33 mA with VBUS connected, which appears to be well below the default 100 mA current limit. Please disregard the earlier estimate of 90–110 mA that I mentioned during the initial investigation with some external debug tools connected, as subsequent measurements indicate the current consumption is significantly lower.

Regarding the rework, yes, the boards currently being tested have undergone rework to remove the compass device. However, the BUCK2 behavior remains consistent across the tested boards (6 Boards):

• Battery only: BUCK2 / 3V3A ≈ 3.294 - 3.33 V
• VBUS connected: BUCK2 / 3V3A ≈ 4.24 V

I will share the scope measurements/waveforms of VBUS, VSYS, BUCK2 output, and SW2 during startup soon.

Regards,