Enable charging while pocketbeagle is off

I’ve configured my pocketbeagle with a 3.7v Li-ION battery and it works fine. It also charges when I power the pocketbeage via the USB connector (and switches seamlessly as USB power comes and goes) . However it won’t charge the battery when the computer shuts down. I suspect something disables charging on the PMIC during shutdown. Does anyone know if it’s possible to tell the system not to disable charging? Or what part of the kernel handles this?

I’ve also successfully read and written PMIC registers using the i2c utilities, for example to reconfigure the upper charge voltage to 4.2v.

Thanks, Dan

I am interested in this, too. Do you have the 10K thermistor and 75K resistor to the thermal sense input?

I'm slowly getting back to this myself. I finally got the parts but now need the time!

The driver is at

History:

Looks like it has been there since about 4.4.

Oddly, I’m not seeing anywhere it gets disabled:

Can you point me at some example commands to read pmic regs? I've been away from pocket beagle for a while.

Thanks for those helpful pointers, Jason. I will dig in.

It definitely stops charging for me and as you see in the response to Fred, I definitely see it charging while the system is booted. Could some other piece of code tell the driver to disable charging on the way down?

Hey Fred,

Here are some answers to your questions:

  1. I have attached a LiPo battery from a Pentax camera that has a built-in 10K thermistor and I put a 75k resistor across the T signal and ground on the pocketbeagle. I also added a 10 uF electrolytic cap between Vbatt and ground on the pocketbeagle per the tps65217 datasheet.

  2. You can use the i2c utilities to get/set values. For example to read CHGCONFIG2 and then reconfigure it for a 4.2v charge level
    i2cget -y -f 0 0x24 0x5
    i2cset -y -f 0 0x24 0x5 0xB0

  3. I also added all the relevant registers to a python script I found in pehrtree’s beaglebone-snippets github repostory. My version is attached here. A typical output is shown below. You can see that all looks good on my pocketbeagle and as I type this, it is happily sucking down around 690 mA from a lab USB power supply (which makes sense based on readings I’ve made w/o a battery - ~180-200 mA for the pocketbeagle and attached USB WiFi dongle + 500 mA for battery charge current).

debian@beaglebone:~$ python powerstatus.py

Querying Beaglebone Black Power Management IC on i2c-0 device 0x24

On battery power only? 0

Charging Battery? 1

PPATH: r[0x1]=0x3f

USB Input current bit 0 = 1

USB Input current bit 1 = 1

AC Input current bit 0 = 1

AC Input current bit 1 = 1

USB Power Path enable = 1

AC Power Path enable = 1

USB current-sink = 0

AC current-sink = 0

STATUS: r[0xa]=0x84

Push Button = 0

USB Power = 1

AC Power = 0

CFGCONFIG0: r[0x3]=0x8

Temp sense error = 0

Pre-charge Timedout = 0

Charge Timedout = 0

Active (charging) = 1

Charge Termination Current = 0

Thermal Suspend = 0

DPPM Reduction = 0

Thermal Regulation = 0

CFGCONFIG1: r[0x4]=0xb1

Charger Enable = 1

Suspend Charge = 0

Charge Termination = 0

Charger Reset = 0

NTC Type = 1

Safety Timer = 1

Safety Timer 0 = 0

Safety Timer 1 = 1

CFGCONFIG2: r[0x5]=0xb0

Charger Voltage Bit 0 = 1

Charger Voltage Bit 1 = 1

Precharge Voltage = 0

Dynamic Timer = 1

CFGCONFIG3: r[0x6]=0xb2

Temperature Range = 0

Term current factor bit 0 = 1

Term current factor bit 1 = 0

Precharge Time = 0

DPPM Threshold bit 0 = 1

DPPM Threshold bit 1 = 1

Charge Current bit 0 = 0

Charge Current bit 1 = 1

PGOOD: r[0xc]=0x7f

LDO2 power-good = 1

LDO1 power-good = 1

DCDC3 power-good = 1

DCDC2 power-good = 1

DCDC1 power-good = 1

LDO4 power-good = 1

LDO3 power-good = 1

powerstatus.py (3.02 KB)

I have done some further research. It seems that the tps65217.c mfd driver in the kernel sets the OFF bit (bit 7) in the PMIC STATUS register (offset 0xA) in order to make sure it shuts down all output voltages (including the RTC 1.8V supply from LDO2) when the system executes a power-down. This bit differentiates between OFF state and SLEEP state when the RTC in the main processor drives the POWER_EN signal low (the kernel sets the RTC alarm with a 1.5s timeout to disable POWER_EN as the final stage in powering down).

According to my reading of the TPS65217 spec it almost completely disables itself if OFF is set when POWER_EN is set low and this includes charging. If OFF is clear then it leaves the ability to charge enabled as well as keeping LDO2 enabled (to power the RTC).

I did some experimentation and verified this. After booting I clear the OFF bit using i2cset and then power down.

i2cset -y -f 0 0x24 0xa 0x00

sudo shutdown now

The battery continues to charge after the system turns off (verified with an ammeter in series with the battery + lead). However there is also an additional ~15 mA load that is left on the battery when it is done charging. I see from the pocketbeagle schematic that a sn74lvc1g07 driver is taking power from the LDO2 output (VDD_RTC). However this chip should take much less than 1 mA so there is something else is taking power. I also notice that the OSD3358 SYS_VDD_3P3V (TL5209 regulator output) is also enabled. It is not normally enabled if the system is shutdown with the OFF bit set. I suspect circuitry in the Octavo module is consuming the extra power.

This high quiescent current in exchange for charging when the system has been shut down is clearly a problem for a battery powered device. I will ask Octavo about this current as soon as my request for access to their forums is granted.

It will be unfortunate if the high quiescent current is unavoidable because of a design decision made by Octavo. The decision to completely disable the PMIC on shut-down was clearly made to work around a bug in the version 1 TI AM3358 silicon (Advisory 1.0.17 in the errata) as well as design decisions by the Beaglebone Black team that could cause a potentially chip-damaging situation if the RTC was powered but the rest of the system was off. This is the “RTC-only mode” bug that you’ll find documented, mainly on kernel threads. However by my reading of TI’s errata and understanding of the pocketbeagle design, it seems that this should be able to work (as well as the RTC-only sleep mode) with the pocketbeagle. That would make the pocketbeagle even that much cooler.

Perhaps I’ve missed something and would love to hear from anyone with additional information. Otherwise I guess this is just information for others in the future.

Additional FYI:

PMIC MFD Driver: https://github.com/beagleboard/linux/blob/7a920684860a790099061b67961d0b5ffa033fdf/drivers/mfd/tps65217.c

RTC Driver: https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-omap.c

To close this thread out, I heard back from Octavo systems. The OSD3358-SM SiP used on the pocketbeagle internally connects the LDO1 regulator (I misspoke above) to both the RTC clock input (VDDS_RTC) as well as the VDDS input. The extra current is taken by the connection to the VDDS power input. So it looks like the pocketbeagle will never be able charge with the system shut down without the extra drain from the battery. The answer from Octavo is copied below. Their C-SiP package may be able to work in this situation.

https://octavosystems.com/forums/topic/unexpected-current-consumption-with-pmic-sleep-mode-for-battery-charging/#post-6895

"The additional current consumption comes from the fact that the OSD335x and OSD335x-SM use TPS65217C PMIC. If you look in the application note from TI (http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf), you can see that in the case of the TPS65217C, both VDDS and VDDS_RTC are connected to the LDO1 output of the PMIC. The additional current consumption that you see is a result of the VDDS power input being connected to the LDO1.

Unfortunately, the connection between VDDS and LDO1 is internal within the SiP and cannot be modified on the OSD335x and OSD335x-SM. However, we are in the process of characterizing the OSD335x C-SiP to see if it can support the power use case where VDDS is not connected to LDO1. We should have that characterization finalized in early January.

Additionally, the TL5209 is enabled with an internal pull up within the OSD335x family of devices. In the OSD335x and OSD335x-SM, this connection cannot be modified. However, in the OSD335x C-SiP, there is a pin, SYS_VDD1_CTL, that will allow a user to disable the TL5209."