Battery Charging with BQ24195L on 4.2.0 vs 6.2.0+

Firmware
1

I have a device that makes use of the BQ24195L battery charger and MAX17048 fuel gauge and let’s the device os handle charging. I have been running 4.2.0 and was considering upgrading to 6.2.0 or higher, but as I was experimenting with battery charging with depleted batteries (4.2V 18650 batteries) that fell below 2.5V, I was finding that the device os would not charge them in 6.2.0+, but would in 4.2.0. During my testing I was able to keep the firmware the same and run particle update –target x.x.x to switch firmware versions.

This is a problem for me, because units may sit on a shelf for many months and battery voltage can fall below 2.5V.

Below 2.5V, the fuel gauge isn’t able to read the battery voltage, which returns -1.

Is there some code I can add to get charging to kick off in 6.2.0? I was thinking of adding something like this, but I don’t want to fight the device os.

    if(wantToCharge) {
        WITH_LOCK(pmic) {
            if(!pmic.isChargingEnabled()) {
                pmic.enableCharging();
            }
        }
    }
2

Did you also use the power manager socBitPrecision call?

The MAX17048 is 19 bit and MAX17043 is 18 bit. The Device OS default is 18. This doesn't quite fit because the PMIC should determine charging without using the fuel gauge, however.

I'd guess that one of the charging parameters is different in the PMIC. I'd dump out the registers on both versions and see if any are different.

3

Thanks for pointing out socBitPrecision, I will utilize it if I can get past these other issues.

I printed my power on, status and fault registers, since they seem the most relevant.

Fault is 0 for both 6.3.4 and 4.2.0

4.2.0

Status: 109 (01101101)

Power On: 27 (00011011)

6.3.4

Status: 69 (01000101)

Power On: 11 (00001011)

The difference between the power on register is that charger configuration is set to charge battery in 4.2.0 and charge disable for 6.3.4.

The difference between the status registers is DPM_STAT is VINDPM or IINDPM on 4.2.0 and not Not DPM in 6.3.4 and CHRG_STAT is fast charging on 4.2.0 and not charging on 6.3.4.

In both cases, I was using USB as the power source. It seems to me that the power manager in the device os is disabling charging by writing to the power on register. According to the datasheet, the default values in the register would enable charging. My firmware does not write to this register and I only set the charge enable pin to enable charging.

4

You might also want to print out the system battery state. If Device OS believes that the battery is not present, it will disable charging. This could be affected by the fuel gauge.

You might need to get trace logs from early boot to figure out what the power manager is doing. The problem is that USB takes a long time to reconnect (especially on Windows) and you'll miss the messages. If you can do Serial1 (UART) debugging, that solves the problem if you are not using Serial1 already and have an appropriate converter (FT232).

5

Also do you have the PMIC interrupt line connected? And configured through the Power Manager interruptPin call? The battery detection algorithm relies on it, and if you don't have that set up properly it might think that battery is not present and disable charging.

6

I don’t have the PMIC interrupt connected, so that may be the problem, if that’s being utilized in the later device os. That being said, I don’t have problem charging the battery once its above 2.5V. The fuel gauge is powered directly off the battery, so the battery voltage is insufficient below 2.5V for it to be able to measure and respond to commands.

I logged the system battery state, on 6.3.4, it is BATTERY_STATE_DISCONNECTED, while in 4.2.0, it BATTERY_STATE_CHARGING.

I have Serial1 logging available, but I didn’t see any useful logs.

Doesn’t seem like there is much I can do here, except to work with the customer to ensure battery voltage is in the valid range prior to final deployment.