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.

TPS65217: How to bring Vsys on the PMIC to low on shutdown

Part Number: TPS65217
Other Parts Discussed in Thread: TPS65910, TPS65218

Hi , 

I am seeing an incomplete shutdown on Beagle Bone Black with the latest linux image. The console output reads " power down" and the I see that the BBB keeping VLDO4 high. As per Mathijs' answer  to the question https://e2e.ti.com/support/power_management/pmu/f/200/t/651787 and https://e2e.ti.com/support/power_management/pmu/f/200/p/651787/2396232#2396232 it is understood that there is some leakage path. This is also mentioned by BB in reply to the question at https://e2e.ti.com/support/power_management/pmu/f/200/p/647421/2386027#2386027.

I am using a BeagleBone Black with Battery connected.. Here, it is noticed that in my BBB the Vsys is always high. Vsys = Vbatt at shutdown. ( I issued the linux shutdown command - "poweroff"). This is found to drain the battery.

Is this expected behavior ?

Will Vsys never be brought down to zero ?

How can I bring Vsys down ?

  • AA,

    You need to verify that OFF = 1b (bit 7 of Status Reg. 0x0A) to enter the OFF state in the TPS65217 state machine.

    The PPATH (power path) will be off and there will not be a connection between SYS and BAT.

    If OFF = 0b, the TPS65217 will enter SLEEP state when PWR_EN pin goes low. In this case, PPATH will be on and VSYS = VBAT.

    I cannot tell you which Linux command will enter the OFF state. You will need to consult the Linux drivers for the TPS65217.

    This "Linux Core Power Management User's Guide" states:

    "RTC-Only Mode

    RTC-Only mode does not maintain DDR context so placing a board into RTC-only mode allows for very low power consumption after which a supported wake source will cause a cold boot. RTC-Only mode is entered via the poweroff command.

    To wakeup from RTC-Only mode via an RTC alarm, a separate tool must be used to program an RTC alarm prior to entering poweroff."

    but also states:

    "Whether or not your board enters RTC-Only mode or RTC+DDR mode depends on the regulator configuration and whether or not the regulator that supplies the DDR is configured to remain on during suspend. This is supported by the TPS65218 in use of the AM437x boards but not the TPS65217 or TPS65910 present on AM335x boards."

     


    Whether or not VLDO4 remains high is not necessarily dependent on the SYS voltage and may be related to the leakage path you mentioned. If this question needs more support from the AM335x processor team.

  • It is noticed from I2C traffic that we are setting OFF bit = 1 on status register (0x0A) at boot up.

    10.77531952 I2C Setup Write to [0x24] + ACK

    10.77534202 I2C 0x0A + ACK

    10.77540129 I2C Setup Read to [0x24] + ACK

    10.77542379 I2C 0x08 + NAK

    10.77548722 I2C Setup Write to [0x24] + ACK

    10.77550972 I2C 0x0A + ACK

    10.77553222 I2C 0x88 + ACK

    10.77773567 I2C Setup Write to [0x24] + ACK

    10.7777914 I2C 0x16 + ACK

    In my case,  

    Only LDO4 is high (due to leakage path as mentioned in other posts) , so I guess it is going to  the state of "Wait_Power_EN" .  Is this correct ?

    PWR_EN toggles (high to low) at shutdown and stays high in the end . I am assuming that the PWR_EN has to go from low to high, rather than just stay at  logic high for state transition of PMIC. So our PMIC is stuck at Wait_PWR_EN stateIs this correct?

  • AA,

    PWR_EN should NOT be a pulse:
    OFF or SLEEP: When the PMIC is in OFF or SLEEP states, PWR_EN pin will be low and stay low
    ACTIVE: when the PMIC is in ACTIVE state, PWR_EN pin will be high and stay high


    The de-glitch time on this pin is 50ms (typical, page 14 w/ spec name "tDG").

    If a short pulse occurs (50-100ms), it is possible the de-glitch time did not expire during this pulse (maximum not spec’d in datasheet), and there is no reason PWR_EN should not hold a low state for at least 1s because:
    There is a 1s delay every time the PMIC transitions from ACTIVE in the Global State Machine (see Fig. 20 on page 39). Since the PMIC
    cannot enter a new state in <1s, the PWR_EN pin should stay low for at least 1s. Pulling the PWR_EN pin high during this time will
    trigger a new transition to the ACTIVE state as soon as the 1s timer expires.
  • The board has battery attached and the ac power

    Linux command of "poweroff" was issued to shutdown the device.

    Please see the attached for complete I2C data from start to shutdown.

    i2c data from start to end.xls

  • Is there a question in your above post?

    PWR_EN went low and the shutdown sequence occurred as expected after 50ms.

    I cannot analyze the I2C data in this format and it makes the entire e2e thread difficult to scroll through.
  • BB,

    There was no question but some supporting images and i2c data(now attached as a separate file instead of inline).
    From your previous answer and my observation, from the image I see that the PMIC_PWR_EN is low for short time 64ms and did not stay there for at-least 1 second as you have pointed out earlier in this thread. We are now investigating why it is not staying low at shutdown.

    Thanks.
  • In the attached Excel file of I2C data,

    I see 3 Read commands to the 0x0A register, and the following data was read back:

    • 9.772541s: 0x26, where the Slave Address in the "READ" line (row 280 of xls file) is 0x24 but the Slave Address in the Write line (278) is 0x12 
    • 9.773586s: 0x3F, where the Slave Address in the "READ" line (row 280 of xls file) is 0x24 but the Slave Address in the Write line (278) is 0x12 
    • 9.7742s:     0x08 = 0000 1000, bit 3 is ACPWR = 1 (AC source is present and in the range valid for charging.)

    I see 0 Write commands to the 0x0A register and the value is never 0x88, meaning in this test the OFF bit was never set to '1'

    These other cases where the Write address is 0x12 do not make sense to me, because the 7-bit slave address should always be 0x24. The 8-bit address is 0x48 for Write and 0x49 for Read, but the Saleae never displays an 8-bit address.

    What you are seeing on the SYS pin is the voltage dropping from the AC value (~5.25V) to the BAT value (~4.2V).

    In the case where a battery is available, it is okay to bring the PWR_EN pin back up after the de-glitch time (50ms) is exceeded because:

    To return to the ACTIVE state with Battery power available, a push-button press (toggle on PB_IN pin) is required.

    So the Linux driver is performing an acceptable action when driving the PMIC_PWR_EN signal.

    I think to solve your problem we need to get back to the original questions:

    1. SYS is always on - yes, this is true. Even in OFF & SLEEP states, when the PPATH is OFF there is a footnote (4), which reads "(4) Battery voltage always supplies the system (SYS pin)"
      • If there are loads on the SYS pin other than the PMIC's DCDCx, LDOx, LSx rails, then they will drain power from the battery in OFF and SLEEP states
      • In order to shut additional SYS loads off, your design would require an external load controlled by an existing or new GPIO. I believe you have a load switch in your design
    2. LDO4 does not go lowThis is not caused by the PMIC. I tested in the lab and the LDO4 rail always goes low when the PWR_EN pin transitions from high-to-low
      • In order to turn off your V3.3C rail, may I suggest you use the PGOOD signal from the TPS65217 to drive the EN pin of this external SYS load switch instead of a voltage rail such as LDO4