NPM1100 Charge expected behaviour questions

[i_4556]

Hello, and thank you for your time. We have designed an NPM1100 into a product, and are unclear on if the behaviour of the charge pin is correct (nor indeed what exactly is the expected behaviour).

Our expectation is the following: when charging is actively occurring, thats to say current is flowing into the battery, the charge pin should be active (low). In all other cases, the charge pin should be inactive (high).

We have noticed the charge pin low when there is no Vusb and our device is operating off the battery. Is this correct, that the charge pin is active when charging could potentially occur (battery voltage within the charge range) even if it is not actually occurring?

Thank you!

[Susheel Nuguru]

The behavior of the CHG (charge) pin on the nPM1100 PMIC is as follows: When the nPM1100 PMIC is charging the battery, the CHG pin is pulled low. This pin is connected to General-Purpose Input/Output (GPIO) P1.00. The CHG pin and the ERR (error) pin sink 5 mA of current when active and are high impedance when disabled. This is suitable for driving LEDs or connecting to host GPIOs in a weak pull-up configuration. The charging indication pin, CHG, is active while the battery is charging which is mentioned here

However, the CHG pin should not be active (low) when there is no Vusb and the device is operating off the battery. If you are observing this behavior, it might be due to some other factors or conditions. It would be beneficial to check the charger error conditions as well as mentioned here.

[i_4556]

Thank you for your reply, however I would like further clarifications please.

Firstly, when you say "When the nPM1100 PMIC is charging the battery" does this mean when current is actively flowing, or just when current could potentially be flowing?

Secondly, the NRF5340 internal pullups are ~13K per the datasheet. Could I connect the LED pin directly to the MCU and use the internal pullup to pull the line high?

Thirdly, if the thermistor is missing, my understanding of the datasheet is that this will cause the NTP to think the battery is too cold to charge. When I test this, both the charge and error lines are high; should I expect the error pin low?

Lastly, if I have Vusb present but no battery, I would expect charge to be high; is this correct?

[Simonr]

Hi

As per the spec. the GPIOs don't have a difference in the internal pullups. Have you tried connecting it to any other pin to see if this is specific to P0.18 or if you see this behavior no matter what the pin config. As per the nPM1100 spec, the CHG pin should be connected to a host GPIO in a weak pull-up configuration, so how have you configured P0.18 exactly? Also, just to make sure, you don't have any mentions of QSPI in your project file otherwise (enabling it in kconfigs or calling the peripheral in the source code for example)?

Best regards,

Simon

[i_4556]

Hello and thank you again for your reply and your help.

When we test with other GPIOs, everything works exactly as expected.

We configure 0.18 as follows:

chargeind: charge_ind {

            gpios = <&gpio0 18 (GPIO_ACTIVE_HIGH|GPIO_PULL_UP)>;

            label = "Batt charging";

            // zephyr,code = <INPUT_KEY_0>;

        };

In my main I then do:

#define BATT_CRG_NODE DT_ALIAS(chargeind)

static const struct gpio_dt_spec batt_charging = GPIO_DT_SPEC_GET(BATT_CRG_NODE, gpios);

static struct gpio_callback batt_charging_cb_data;

And finally

gpio_pin_configure_dt(&batt_charging, GPIO_INPUT | GPIO_PULL_UP);

I double checked and I do not enable QSPI in my configs, although I do enable the regular spi peripheral (but not on 0.18 obviously).

I am using MCU Boot; could it be that I need to do config_qspi=n in the mcuboot config?

Thank you for your help!

[Hieu]

Hi i_4556,

You suspect right that MCUboot has different configuration compared to the application. However, since you don't seem to be using QSPI external flash in your project, in most case, QSPI should not be enabled in MCUboot,

Nevertheless, since disabling QSPI explicitly in the application yielded you some result, you could try to do so for MCUboot as well.

Please also remember to check if QSPI is actually enabled/disabled in MCUboot by looking into the .config and zephyr.dts files in <build directory>/mcuboot/zephyr.

Hieu

[i_4556]

I think we may have found the source of the problem; I used your suggestion of checking the zephyr.dts files in both my application and the mcuboot. It is disabled in my application, but enabled in mcuboot.

How do I disable QSPI in mcuboot? I have no real experience working with mcuboot, other than some tweaks in the mcuboot prj.config file... I am using SDK 2.5.0 and Visual Studio Code if that matters...

This looks a lot like this issue here:  SDK 2.3.0 - can't disable qspi in DT overlay file?

Do I just need to create a file called mcuboot.overlay in my mcuboot folder, and then add

&qspi {

    status = "disabled";

};

to it?

[Hieu]

i_4556 said:

Do I just need to create a file called mcuboot.overlay in my mcuboot folder, and then add

This is almost it. The correct file you should create is <project root>/child_image/mcuboot.overlay.

For more information regarding configuring child images, please refer to this documentation:
Multi-image builds — nRF Connect SDK 2.6.1 documentation (nordicsemi.com)