TPS2113: Glitch on TPS2113's output

Hi Andy,

If my understanding is correct, then when the USB supply is disconnected from the TPS2113, the output of the device drops to reset the system before switching over to the new supply. I have a few questions on this:

1. How are you switching between supplies? Are you setting a voltage threshold, and if so, what is the value of the threshold?

2. What voltage is the output of the switch dropping to when resetting the system? What is acceptable?

3. How much capacitance do you have on the output of the TPS2113?

4.  What is the current load of the system?

Also, have you taken a look at the TPS2113A? This device is the same as the TPS2113 except the switchover time between supplies is a bit quicker.

Thanks,

Alek Kaknevicius

Hi Alek,

Thank you for looking into this issue. Here are the findings:

1. Switching the power by pulling out the USB input / power cable from the board's connector. Design is set for auto switching.

2. In the process of collecting the droop data when glitch occurs.

3. We have 10uF ceramic cap on output. Regrettably it is not placed right at the output pin. It is about 12+ mm away. from the output pin, and  but much closer to the  5V-3.3V  LDO's input pin.

We have used TPS2113PWR unit before without any trouble, but moved to TPS2113ADRB part on this rev to have more current headroom. The difference between the previous and current rev are:

a) Output cap is far away now,  b) VSNS pin 3 connected to main USB-5V (pin 8, IN1) through inner layer. IN1 is routed on top layer but VSNS is routed from IN1 on inner layer with 2 contacts.

We did this routing on top layer  for the previous board. c) We pulled STAT pin to 3.3V with 1M and routed to MCU so we can monitor the status pin. Previously it was pulled to OUT. and we were not monitoring it.  Can these differences cause this trouble?

4. Load is closer to nothing, it fails when the board is idle and we pull USB cable out , power does not switch over to the battery voltage which is up at 4.2V for pin IN2, so the problem is fundamental, something is incorrect. 

Hi Andy,

I don't see anything too concerning based on what you said. While I understand that the output capacitor had to be put farther away, would it be possible to increase it from 10uF to something higher (maybe 47uF or 100uF)? This should reduce the droop when switching between supplies and may help to see if this is the issue.

Thanks,

Alek Kaknevicius

Thanks Alek, will do that and post the findings when we have data after the change. There is a load switch TPS22912C we have on the battery load path; it is there so we can turn off the power from the battery

when the battery's  charge capacity reaches certain limit  (BATT_LOAD path to TPS2113 mux is blocked by the load switch with MCU intervention).  When USB power goes away the voltage on battery load path drops from 4.64V to 4.10V. If the reverse current flow is creating this glitch or higher capacitor on PMUX OUT will eliminate this glitch i s under validation. If the reverse current through the load switch is causing it then we need a diode to block this path (that load switch for some reason is not blocking).  

Thank you much for helping.

- Andy

Hi Andy,

How is the TPS22912C configured here? Is the enable pin of the device high when you are looking for RCB to take effect? When enabled, the TPS22912C relies on measuring a voltage difference between VOUT and VIN to enable reverse current blocking. For more information on RCB (specifically for this type of device) you can take a look at section 5.3 in the app note below:

Thanks,

Alek Kaknevicius

Thank you Alek for the RCB document. Here is a screenshot, which shows power supply PMUX's out (5V, yellow) and 3.3V (blue).  When USB power is removed 5V collapses and follows the output of  LDO 3.3V and then recovers to the battery voltage 4V. The system reboots in the process. 

The load switch 22912C is turned on by 3.3V, but this validation also revealed that we have a BOM error, we should be using 22910A switch ( grounded p-gate, always on) rather than N-gate 22912C.  We had to hard wire the switch's input to 3V so it stayed on for the Battery voltage to be available at the PMUX's input 2.   I think we can remove the switch completely and route Vbat directly to PMUX's  IN2. Hopefully, this will eliminate the issue without beefing up the output capacitor; if not then we are in trouble.

Thank you for helping us out.

- Andy