• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 3 answers
  • Subscribers 65 subscribers
  • Views 2276 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS65720: Standby current for TPS657201Y around 1 mA

Tomas Barregard
Prodigy 90 points
Part Number: TPS65720

We are using TPS657201YFFR as a single PMIC in a battery driven product. It handles all power management in the design. We have a problem with the standby current (that is when HOLD_DCDC1 is low and PB_IN is pulled high using VSYS). We see a current being drained from the battery (3.7 volt) of about 1 mA going into BAT1/BAT2. My measurements show that there is no significant current being sourced by L1, VLDO1 and SYS1/SYS2. This makes me believe that the current is being drawn by an internal circuit of the TPS657201.

 

I have noticed that if we remove and then reinsert the battery the standby current is instead around 0.01 mA which is much more reasonable.

 

Do you have any idea why turning off the PMIC using HOLD_DCDC1 and PB_IN results in such a high standby current?

  • 0
    TI__Genius 9380 points
    Tomas,
    I have forwarded your question to an product specialist. You should have an answer soon.
  • 0
    TI__Mastermind 30310 points
    It sounds like you have force PWM turned on, F_PWM = 1b

    F_PWM is bit 7 of Register 0x09 and the quiescent current is heavily dependent on whether or not the device can enter PFM (power-save mode).
  • 0 in reply to Brian Berner
    Prodigy 90 points
    Hi Brian,

    I´m Tomas co-worker and one of the software guys in the project.

    I did a register dump right before we pull HOLD low (i.e. turns off the product) to get a clearer view, this is the outcome:
    CHGSTATUS [0x01] = 0x00
    CHGCONFIG0 [0x02] = 0x4F
    CHGCONFIG1 [0x03] = 0x74
    CHGCONFIG2 [0x04] = 0x4C
    CHGCONFIG3 [0x05] = 0x41
    CHGSTATE [0x06] = 0x40
    DEFDCDC1 [0x07] = 0x64
    LDO_CTRL [0x08] = 0x7C
    CONTROL0 [0x09] = 0x00
    CONTROL1 [0x0A] = 0x13
    GPIO_SSC [0x0B] = 0x0F
    GPIO_DIR [0x0C] = 0xF3
    IRMASK0 [0x0D] = 0xF3
    IRMASK1 [0x0E] = 0xFF
    IRMASK2 [0x0F] = 0xFF
    IR0 [0x10] = 0x00
    IR1 [0x11] = 0x00
    IR2 [0x12] = 0x00

    As you can see F_PWM is 0.
  • 0 in reply to Henrik Smeds
    TI__Genius 9380 points

    Gentlemen,

      I have looked over the register values and didn't see anything that stood out as a problem. Would it be possible to get a copy of your schematics?

    You can send it directly to me if you do not wish it to be public.

  • 0 in reply to Gordon Varney
    Prodigy 90 points
    Hi Gordon,

    I have sent a message here on E2E with schematics and some notes to you, please forward to Brian Berner if necessary.

    BR Henrik
  • 0 in reply to Henrik Smeds
    Prodigy 90 points

    If you have any questions about the schematic or hardware design you can let me know.

     

    When the TPS65720 is turned off (that is HOLD_DCDC1 is low and PBIN is pulled high by VSYS) we have noted the following:

    - The current going out from the pins SYS1 and SYS2 is very low and neglectable.

    - There is no measurable current going out from the pin VLDO1.

    - There is no measurable current going out from the pins L1/FB_DCDC1.

    - We can measure that a significant current close to 1 mA is going in to the pins BAT1/BAT2.

    - We can sporadically see a current going through the temperature resistor R25. This current alone can not account for the drain on the battery that we measure.

     

    In general the pin AC is not connected during these measurement (we are not using any charger during the test).

    Note that this is intended to be a very lowpower design. That means that the nets VSYS, +1.8V and +3V are more or less floating when the processor is turned off. There are no pull-down resistors for on these nets anywhere in the design.

  • 0 in reply to Tomas Barregard
    TI__Genius 9380 points
    Tomas,
    I am working with the chip designers on this. We would like to see a scope shop showing E2 (L1) Pin. We want to verify that the part is in PFM mode. I realize that the registers are not forcing PWM, but that does not mean that the part is making it to PFM mode.
  • 0 in reply to Gordon Varney
    Prodigy 90 points

    The purple signal is the button (B1) measured on pin 2. The blue signal is HOLD_DCDC1. The yellow signal is pin E2 (before the inductor). The green signal is the net +1.8V measured after the capacitors C41 and C42.

    You can see that the yellow (pin E2) and green (net +1.8V) signals decrease quite slowly. I believe that this is because the product is a lowpower design so once the processor is turned off there is nothing actively loading the net. You can see that the blue signal (HOLD_DCDC1) starts to slowly rise once the button is released. Once the processor is shut down there is nothing actively loading this net so it somewhat starts to float.

  • 0 in reply to Tomas Barregard
    Prodigy 90 points
    I have noticed that the current going into the PMIC (pin BAT1 and BAT2) is somewhat proportional to the battery voltage.

    3.3V -> 0.5 mA
    3.7V -> 0.9 mA
    4.2V -> 1.2 mA

    This only applies when the device is in this buggy shut down state. If the battery is disconnected and reinserted the current is as mentioned earlier around 0.01 mA.
  • 0 in reply to Tomas Barregard
    TI__Genius 9380 points

    Tomas,

      Thank you for providing very detailed information. Sometime we have to solve problems with little or no information. This really does help.

    I have not heard back from the chip designers yet. I will follow up to see if they have anything.

    I also have not been able to reproduce this extra current on an EVM.

    I will keep trying to see if anything changes.

  • 0 in reply to Gordon Varney
    Prodigy 90 points

    Hello,

    I believe we have managed to isolate the issue. We loaded the device with a special primitive software. This primitive software makes the processor turn on the TPS65720 using HOLD_DCDC1. After a few seconds the TPS65720 is turned off pulling HOLD_DCDC1 low. There is no I2C commands send to the TPS65720 so it is using all default values.

    We noticed in this test that the current into BAT1/BAT2 is low after the TPS65720 is shut down. The current consumption is the same as if we would have disconnected and reinserted the battery. I believe that this points towards that the issue with 1 mA current lies within the state-machine of TPS65720 or how it responds to the register settings that are made through I2C.

    Best regards

    Tomas

  • 0 in reply to Tomas Barregard
    Prodigy 90 points

    Same device as previous measurement (no changes to the hardware). Same instrument and same test setup. The only difference is the software running i the processor.

    Signal colors are the same as previous (The purple signal is the button (B1) measured on pin 2. The blue signal is HOLD_DCDC1. The yellow signal is pin E2 (before the inductor). The green signal is the net +1.8V measured after the capacitors C41 and C42).

  • 0 in reply to Gordon Varney
    Prodigy 90 points

    Picture 3

    Picture 4


    We tried two new softwares to find out if there is any unexpected behavior in the state machine of TPS65720. Picture 3 and picture 4 (above) show the shut down sequence. Signal colors are the same as previous (The purple signal is the button (B1) measured on pin 2. The blue signal is HOLD_DCDC1. The yellow signal is pin E2 (before the inductor). The green signal is the net +1.8V measured after the capacitors C41 and C42).

    The two new softwares change state of HOLD_DCDC1 and PB_IN in a different order to see if there is any dependency. Both these softwares give a reasonable shut down current. This points towards that the problem is related to I2C.

  • 0 in reply to Tomas Barregard
    TI__Mastermind 30310 points

    Tomas,

    You might have mentioned before, but could you tell me if you are testing the TPS65720 device on an EVM or on your board?

  • 0 in reply to Brian Berner
    Prodigy 90 points

    We are testing it on our board (the one that we provided schematic for).

  • 0 in reply to Tomas Barregard
    TI__Mastermind 30310 points
    If you measure the voltages VAC and VSYS with a multi-meter, what are they?
  • 0 in reply to Brian Berner
    TI__Mastermind 30310 points

    In the Register dump you provided early on in this thread, it says:

    CHGCONFIG0 [0x02] = 0x4F

    The default (reset) value for this register for the TPS657201 is 0x6F

    When this Register == 0x6F, then VSYS[1..0] = 01b, AC input current[1..0] = 10b, which means that the DPPM is Disabled.

    In this case, the SYS voltage is un-regulated.

    When AC input current[1..0] = 00b, the DPPM is enabled and VSYS is regulated and will be 4.4V when VSYS[1..0] = 01b

    Although the load on SYS should be low, the current consumption could be coming from the DPPM circuitry itself or the PMIC is burning current in order to generate VSYS = 4.4V from VAC = 5V (typical) or higher.

    This may not be the root cause of the issue, but it was the first mismatch I identified with the TPS657201 default registers and the data dump you provided.

  • 0 in reply to Brian Berner
    TI__Mastermind 30310 points

    I am also concerned with the values that I found in Reg. 0x0A, CONTROL1

    The value from the Register dump you provided is:

    CONTROL1 [0x0A] = 0x13

    According to this table: the push-button is still pressed, the OPAMP_MUX is measuring the battery voltage, and the OPAMP and MUX are enabled.

    Any one of these things can be adding to the quiescent current. Adding all of these factors together could account for all of your current consumption.

  • 0 in reply to Brian Berner
    Prodigy 90 points
    Thanks for the input. I think we are on to something here. One of my colleagues will try it out and comment on it.
  • 0 in reply to Brian Berner
    Prodigy 90 points
    Thanks for the help. Only setting OPAMP_EN = 1 when actually measuring the battery solved our issue.