nPM1300 Quiescent Current

[Jared]

I've been testing the nPM1300 and I'm running into some interesting issues. I'm using NCS 2.7.x (originally evaluated on 2.6.x) and got it to the sweet spot where the nRF9161 + nPM1300 was drawing < 10uA. (or so I thought until I revisited it!)

Here's how it's being used:

• Initializing buck2 with a 255K resistor supplying 3.3V
• Keeping buck1 on at all times at 2.7V (255K resistor) (are these VSET values OK for maxing out the regulator?)
• All LDO output/inputs are grounded and unused

Buck2 is only used when USB is connected. When disabled, I'm seeing a range of quiescent currents from 8uA up to 108uA depending on when the device is being configured (Seems like possibly related to https://docs.nordicsemi.com/bundle/errata_nPM1300_Rev1/page/ERR/nPM1300/Rev1/latest/anomaly_300_31.html?) I saw that reading from the device prevents this high Iq but it still seems higher than expected.

Additionally, as a different issue but potentially related, whenever I probe the SDA line with my multi-meter, nPM1300 increases current draw to 1mA and doesn't go back down unless reset.

ketiljo has already looked at the design and I've addressed the functionality concerns a while back.

Is there anything I can do to get the operation to be more stable/repeatable? Depending on how long the device is powered (or not powered at all) I get different quiescent currents at the battery. (Powered only on 3.6V on a bench supply via a JouleScope)

By the way my device tree def is as follows:

	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>;
			};


		};
	};

To add to the fun, I've noticed that when warmer I get closer to the expected quiescent current of about 4uA. (measured post hot air rework) Once it cools off it can land anywhere in the aforementioned range.

I've disabled the configuration in the mcuboot image:

CONFIG_REGULATOR=n
CONFIG_REGULATOR_NPM1300=n
CONFIG_MFD_NPM1300=n
CONFIG_I2C=n
CONFIG_GPIO_NPM1300=n
CONFIG_NPM1300_CHARGER=n

But allow the default regulator and MFD initialization calls to happen during boot. I did notice that the buck status register gets read a couple times during init. Doing that after enabling the buck2 pulldown and disabling the buck2 output appears to help reduce the quiescent current from 100uA to 10uA. (my thoughts why it could be related to [31] BUCK: Increased BUCK Hysteretic quiescent current)

Any help is greatly appreciated.

[Håkon Alseth]

Hi Jared,

 

Jared said:

With that said, seems like an issue on the top layer which includes a SPI NOR flash and nRF9161. Looking into it more.

Are you still suspecting that the issue is related elsewhere than the npm1300?

For instance the flash not going into DPD mode?

Jared said:

Simply using a Fluke179 and measuring between SCL & SDA. It is resolved with reprogramming the devices via I2C. Maybe related to [27] BUCK: Programming BUCK voltage increases current consumption? Since it increases about 1mA.

This aligns with errata that you mention:

https://docs.nordicsemi.com/bundle/errata_nPM1300_Rev1/page/ERR/nPM1300/Rev1/latest/anomaly_300_27.html

Have you tried the outlined workaround to see if the current lowers afterwards?

 

Kind regards,

Håkon

[Jared]

Håkon Alseth said:

For instance the flash not going into DPD mode?

I'm using the same active_sleep sample that I had for the nRF9160 Feather. Which was appropriately putting the system into sleep <10uA for the whole device. (including putting the SPI NOR into DPD) I probably should confirm it's still working since my upgrade to NCS 2.7 otherwise it may be a firmware problem!

Håkon Alseth said:

Have you tried the outlined workaround to see if the current lowers afterwards?

Yep, If I read or write from the device the current goes back down to what I expect.

I assembled the other side of the two boards I tested earlier. More playing around with it today.

[Jared]

Ahhh. Definitely a firmware issue. I get current ranging from 30 to 80 uA with the same code on the nRF9160 Feather on NCS 2.7 whereas with NCS 2.5 I get ~8 uA on the board I'm testing.

Any ideas of what may have changed to affect the active sleep? I know the modem API has changed a little. Anything else I need to call explicitly?

In NCS 2.5 this was the process:

• Disable/disconnect all relevant GPIOs
• Disable the accelerometer into deep sleep
• Init the modem lib and run lte_lc_init() (removed lte_lc_init in 2.7 since it is no longer)
• Disable UART console

Seems like something else is running or not being put into sleep in NCS 2.7

[Jared]

Looks like the flash driver no longer puts the flash into DPD after init. I elected to put it in manually with this:

int nor_storage_init(void)
{

  static const struct device *spi_nor = DEVICE_DT_GET(DT_NODELABEL(w25q32jv));

  /* Disable console UART */
  int err = pm_device_action_run(spi_nor, PM_DEVICE_ACTION_SUSPEND);
  if (err < 0)
  {
    printk("Unable to suspend SPI NOR flash. (err: %d)\n", err);
    return err;
  }

  return 0;
}

Significant improvement. I think the current issue is resolved on the nRF9160 Feather side. Still having issues getting the current to the correct level on the nRF9161 version. Any other insights or thoughts would be appreciated!

[Håkon Alseth]

Hi,

 

Great to hear that the issue is solved for one board.

Jared said:

Still having issues getting the current to the correct level on the nRF9161 version.

Have you checked if this could be related to the t-enter-dpd / t-exit-dpd timing parameters?

By looking at the datasheet for your chosen flash:

https://www.mouser.com/datasheet/2/949/w25q128jv_revf_03272018_plus-1489608.pdf?srsltid=AfmBOorY8er4aI26BVvIqI_Rqugvc9PiFU17dZEd6deYxTFG3throUTw

The worst case scenario for exit/enter DPD is 30 us (page 65):

/CS High to next Instruction after Reset | tRST(2) | 30 µs

 

It seems that your DT specifies 3.5 us, if I read it correct.

 

Kind regards,

Håkon