Connecting the npm1300 to a custom board

Good Day.

I'm trying to run the "npm1300_fuel_gauge" example on a custom board (nRF52840), but I'm getting errors that I don't know how to fix. 

The first thing I did was to get the PMIC configuration overlay file (config.overlay) through nPM PowerUP. Then I transferred the code from config.overlay to the custom board device tree file (custom_board_nrf52840.dts). I plan to connect the PMIC via I2C1. 

custom_board_nrf52840.dts -->

custom_board_nrf52840-pinctrl.dtsi -->

The following errors occur in the .dts file (see screenshot).

I know that these values should be taken from the "fuel_gauge.h" file, but that doesn't happen for some reason.

I see an error in the prj.conf file too (see screenshot). 

When building the project, I see the following information -->

I have not changed the CMakeLists.txt files. 

Can you please tell me where I am making a mistake when transferring this example to my custom board?

Thank you.

Parents
  • Hi,

    Looks like NPM1300_LDSW_MODE_LDSW is not defined for that file.

    So I searched for that in the nRF Connect SDK and found it used in zephyr/boards/shields/npm1300_ek/npm1300_ek.overlay.

    At the top of this file, there is an include:

    Could you by chance, be missing this?

    Regards,
    Sigurd Hellesvik

  • Hi Sigurd, thank you for your response.

    Yes indeed, I didn't add that inclusion to the device tree file. After that, there was no error with the NPM1300_LDSW_MODE_LDSW detection.

    But cmake errors were still present.

    These errors were resolved by modifying the CMakeLists.txt file -->

    After that, the project build went through without errors. 

    But the application terminates (return 0) after -->

    Do you have any idea what this could be related to? All connections and jumpers are set according to the example.

    Also, I would like to ask if it is mandatory to use npm1300_ek.overlay? What is the point of using the config.overlay file from nPM PowerUP if it will be overwritten by npm1300_ek.overlay?

    Thanks.

  • A bit of a nitpick, but since your only red ring was where you included batter_model, it is good to check:

    Did you remember to use it for the init as well?

  • The TTE=nan could be either an error with the floats themselves or with the print statement.
    To check which:

    Could you debug the application, and add a Watch for the tte and ttf values?

  • Hi Sigurd.

    Now the value of TTE and TTF are calculated. The text files contain TTE and TTF measurement results, the reading update time is 10 seconds.

    1. Can you please confirm that these TTE values are normal?



    2. TTF's readings look adequate and similar to the truth))

    But pay attention to the moment when the charge percentage becomes 100% (current is 50 mA ). 

    The charging process does not stop because I(BAT) > I(TERM). In my case, the charging current is set to 120mA, so I(TERM) defaults to about 12mA (10% of I(CHG)).  And the actual charging is only turned off after an additional 80 minutes when I(TERM) drops to 15 mA.

    How can I make it so that charging turns off immediately when SoC = 100%?

    I know I can set I(TERM) = 20% of I(CHG), but in that case I still have to wait a fair amount of time for I(BAT) to drop from 50mA to 25mA.

    I'm hoping for your help.

    Thank you.

  • backstreet.devisor said:
    1. Can you please confirm that these TTE values are normal?

    How long are these logs for (time)?

    backstreet.devisor said:
    How can I make it so that charging turns off immediately when SoC = 100%?

    So the Fuel Gauge library says that it "processes battery measurements made by Power Management ICs (PMICs) and provides a state-of-charge (SOC) prediction, along with other metric"

    So it only reads out and does not control the charging.

    The PMIC itself controls the charging, and it has a charge cutoff by its termination voltage.
    Configure this to decide when charging should stop.

Reply
  • backstreet.devisor said:
    1. Can you please confirm that these TTE values are normal?

    How long are these logs for (time)?

    backstreet.devisor said:
    How can I make it so that charging turns off immediately when SoC = 100%?

    So the Fuel Gauge library says that it "processes battery measurements made by Power Management ICs (PMICs) and provides a state-of-charge (SOC) prediction, along with other metric"

    So it only reads out and does not control the charging.

    The PMIC itself controls the charging, and it has a charge cutoff by its termination voltage.
    Configure this to decide when charging should stop.

Children
  • 1. Measurement time about 50 minutes with an update period of 10 seconds.

    2. I am using a 600 mAh LiPo battery. The technical documentation says: 

    Normal Voltage - 3.7V

    Initial Voltage - 3.85-3.95V

    Limited Charge Voltage - 4.2V

    Standart Charging Current - 120 mA (0.2C)

    Standart Charging Time - 6-7 hours

    Standart Charging Method - 0.2C CC current charge to 4.2V, then CV charge till current declines to 0.01C.

    Here is my overlay file with the PMIC charging settings:

    So I need to specify a lower value of V(TERM) than 4.2V (according to the technical documentation of the battery)? What is the usual value of V(TERM) set when charging such batteries? 

    Thanks.

  • One other thing I'm curious about...

    When profiling the battery, I set the voltage to 4.2V and the charge current to 120mA. If I now change these parameters (voltage and current) in the overlay file for PMIC, will it affect the algorithm for calculating the battery charge?

  • backstreet.devisor said:
    So I need to specify a lower value of V(TERM) than 4.2V (according to the technical documentation of the battery)? What is the usual value of V(TERM) set when charging such batteries? 

    I think V(TERM) is usually between 4.1V and 4.2V, but to be sure I have asked our PMIC experts.

    backstreet.devisor said:
    When profiling the battery, I set the voltage to 4.2V and the charge current to 120mA. If I now change these parameters (voltage and current) in the overlay file for PMIC, will it affect the algorithm for calculating the battery charge?

    I do not quite understand why you ask this?
    Myself, I do not know the algorithm, but it would make sense that changing the speed and max for a battery charge, you will affect the algorithm a bit. Like, it should show that you are done sooner if you choose 4.1V instead of 4.2V, no?

  • Hi.

    I got it. Thanks for your answers.

    This ticket can be considered closed. 

  • Sigurd Hellesvik said:
    I think V(TERM) is usually between 4.1V and 4.2V, but to be sure I have asked our PMIC experts.

    They say "The overlay file looks correct for his battery. "
    And they add some bonus info: "Once Vbat reaches 4.2V nPM1300 will keep charging in CV mode (Vbat 4.2V) until charge current drops to 0.1C (10% of Ichg), above the customer battery limit of 0.01C (1% of Ichg)."

    That is what you wanted to know, right?