Charge Termination with TWL6032

David,

at end of charge, PMIC generated an interrupt and send it to processor. Gaining that interrupt software has full control to do what ever software deviceds. first thing to be checked is what commands software is issuing .

secondly is there any king of OVP or OCP on the source, if so that should be checked. As turining off the source is not controlled by PMIC.

Hope this helps!

Hi Puneet,

This behaviour happens during uBoot where there is no thread, irq support or any software running.

Basically, we wait in the uBoot shell and this happens.

So maybe there is an IRQ - but the software can't respond.

Gil

There is no OVP or OCP on our power supply source.  We measured VBUS at PMU input during this state - we see a minimum of 4.68V, so the input source looks OK and anticollapse should not be activating.  We are using AUTOCHARGE and so are using HW charge control at termination.  Is there any way this could turn off the DCDC.

Dave

David,

anticollapse reduces the current from the VBUS to stop the sagging of VBUS. Are we sure that DCDC is stop not just the charging current is reduced to zero.

Another thing to check if what is VSYS voltage and PMID voltage. This can tell the charger is not going to sleep mode.

VBUS is OK.  VSYS voltage drops sharply upon charge termination.  This is the problem.  We don't know why.  Can you please explain how PMID voltage works to affect the collapse of VSYS.

Also, attached is the register dump from the TWL6032 - this is the initial configuration set in uboot - no reconfiguration is performed anytime after.  Is there something in this configuration that would cause system voltage to drop and USB DC:DC source to stop when charging terminates.

0000: 51 04 32 c0 00 00 00 00 01 00 00 00 00 00 00 10    Q.2.............

CHRG_PMID is in the power supply for the charger, there is a protection FET b/w VBUS and PMID, so power comes from VBUS to PMID .

VSYS should not drop on charger termiination as it is provided either by battery or by the AC input.

what is the load on VSYS, if VSYS is laoded heavly then it would collased on limited power supply.

Please check the laod.

We have checked our system further.  We have found that upon charge termination the PMIC changes from charging mode immediately to battery only mode (the power path FET changes from a drop of 0.1V during charging to being fully turned on for discharge - the voltage delta from Vbat to Vsys becomes 0V).  Then, after about 2.5S the battery only mode stops and charging mode is regained.  We also see the USB current drop from its charging state of 300 mA to 0 mA at charge termination (like the DCDC is turned off) and then it recovers to 200 mA after 2.5S when charging mode recovers to power our 200 mA load.

Can you please advise what PMIC configuration can exhibit this behaviour.  This is totally not what we expect to see at a charge termination.  We need help in determining what could cause this.  Remember we are using power path.

We have eliminated the USB source collapse as a possible cause - we changed to a 5V, 3A power supply.

We have eliminated input current limit as we changed it to 1.5A and our load draws only 200 mA.

SW is not the problem.  Our system does not have interrupts enabled (it is in uboot only) so SW is not changing anything after charge termination.  THis is a HW configuration mode or some wierd hardware behaviour only.

Please help.

David, this recovery after 2 sec tells me that there is a fault. If there is a charger fault then charger ties to ceck back after ever 2 sec or so, to make sure fault dissappear.

Do you mean that after charging, a charging fault will cause the system to stop charging and revert to battery only mode?  Which faults would you expect.  We will dump our registers during the condition.

We have resolved our problem by implementing the SW fix in the TPS6032 end of charge app note attached.

We are as yet unable to explain where the problem originates however.  We cannot measure any VBUS or PMID rail over voltage conditions or have any indication of which fault condition occurs other than that the LINCH_GATED bit is set in CONTROLLER_STAT1 register and that the CHARGERUSB_FAULT bit is set in the CHARGERUSB_INT_STATUS register, but there is no indication what sets these bits.

We need to determine root cause to be comfortable with our fix.