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: Power down sequence

Part Number: TPS65217
Other Parts Discussed in Thread: AM3352

Hi,

I received the question from the customer.

We are testing one of our products and we are getting an incorrect power-down sequence.

The PMIC does not have a battery connected. PMIC register settings are default, and shutdown procedure is initiated by Linux shutdown -h now command. Hardware implementation is similar to beaglebone black schematics, but with FB_WLED LCD backlight implementation. Our power-on sequence is correct:

 [SYS_5V] -> [VDDS_RTC (LDO1)] -> [LDO2 (3.3V),LDO3 (1.8V), LDO4 (3.3V)] -> [ VDDS_DDR (DCDC1)] -> [VDD_MPU (DCDC2), VDD_CORE (DCDC3)].

 But our power-down sequence is not:

 [SYS_5V] -> [LDO2 (3.3V), LDO4 (3.3V)] -> [VDD_MPU (DCDC2), VDD_CORE (DCDC3)] -> [LDO3 (1.8V)] -> [VDDS_DDR (DCDC1)] -> [VDDS_RTC (LDO1)].

 What is this cause?

Is this why V_SYS drop ahead...?

Best Regards,

Kuramochi

  • Kuramochi-san,

    We are taking a look at this. We will re-sync back up with you on Monday.

    Regards,

    Paul Kundmueller
  • Kuramochi-san,

    Does the customer have a screen shot of the power down sequence? Does Linux shutdown -h now command shut down the 5V power supply? If it does, TPS65217 might be hitting its digital reset before the device is able to complete its programmed power down sequence. Let me know if the customer can provide a screenshot or if the 5V power supply is being disabled. Also let me know if there are any questions. Thanks!

    Regards,

    Paul Kundmueller

  • Paul-san,

    Yes, the 5V output of the TPS65217 is being shutdown by the shutdown -h now command.  Is the digital reset controlled by a register setting? Our nRESET pin of the TPS65217 is not connected.

    Here is a screenshot of the power down sequence:

    TPS65217 down sequence.xlsx

    Best Regards,

    Kuramochi

  • Hi Paul and Kuramochi-san,

    I am the said customer. Just to add some information.

    Regarding the possibility of a digital reset being triggered. It may be connected to one of our other issues. When we use the Linux shutdown -h now command, the board will shutdown then start up again after 1 second of SYS_5V power down. 1 second is the minimum reset state of the PMIC. This happens intermittently, but more often it starts up again. We thought this was due to another reason, but I'm thinking now they are related.

    Regards,
    Jesse
  • Paul-san,

    Jesse-san is my business partner.
    Could you follow this thread?

    Best Regards,
    Kuramochi
  • Hello everyone,

    Just adding some more information. 

    We did some tests by adding some capacitors on the SYS_5V rail to supply the regulators while they complete the shutdown.  We were able to get the following sequence.

    [DCDC2 - VDD_MPU; DCDC3 - VDD_CORE] --> [3.3V_LDO2; 3.3V_LDO4; 1.8V_LDO3] --> [DCDC1 - VDDS_DDR] --> [1.8V_LDO1 - VDDS_RTC]

    Now, this is still off as compared to what the TPS65217 datasheet says.  DCDC1 - VDDS_DDR is supposed to shutdown before the 3.3V and 1.8V LDOs. But, what's important to us is if this in anyway will damage the SoC it's powering?

    We have the PMIC connected to an AM3352 SoC in similar fashion as a Beaglebone Black. What should we be looking out for in terms of power down sequence? 

    Thanks and regards,

    Jesse

  • Hi Jesse,

    Sorry for the delay. Could you try to see what the power down sequence is if you were to de-assert PWR_EN and leave the 5V supply to the PMIC enabled? Even with the added capacitance, I still don't believe there is sufficient time for the device to properly shutdown its rails. Meanwhile I will look at the considerations of having the VDDS_DDR rail power down after the 3.3V and 1.8V supplies. I think this should be okay for the processor but let me confirm this with the processor team. The main concerns for the AM335x power down sequence is ensuring that the 3.3V supplies are sequenced down before the 1.8V supplies are and that the difference between the 3.3V supply and 1.8V supply doesn't exceed 2V. Let me know if there are any questions. Thanks!

    Regards,

    Paul Kundmueller

  • Hi Paul,

    Thanks for the response.  How can I de-assert PWR_EN pin itself? I believe this can only be triggered by an Alarm2 event by the shutdown command. I'm a bit skeptical in physically pulling the pin to ground.

    Thanks,

    Jesse

  • Hi again, Paul,


    I took a chance and disabled the PMIC_POWER_EN function in the processor (PWR_EN always HIGH) and physically pulled the PWR_EN pin low.  We got the following sequence:

    [DCDC2 - VDD_MPU; DCDC3 - VDD_CORE] --> [3.3V_LDO2] --> [1.8V_LDO3; DCDC1 - VDDS_DDR]

    This time 1.8V_LDO1 (VDDS_RTC) did not shut down.  And 3.3V_LDO4 only dropped down to around 2.3V. This hints that the PMIC is in a WAIT PWR_EN state (except for the LDO4 behavior).

    I noticed, however, that the overall system is shutdown while the PWR_EN pin is low, and starts up again when released. In our original waveforms, the PWR_EN pin would have a 10ms HIGH pulse just as SYS_5V drops. I'm wondering if this could be the source of that "digital reset" that could be cutting the shutdown sequence and, most of the time, restarting the system after around 1sec?

    Regards,

    Jesse

  • Paul-san,

    Could you follow us?
    Please let me know if your have any question.

    Best Regards,
    Kuramochi
  • Hi Jesse,

    Would you be able to share your schematic? I have sent you a private message that will help for you to share your schematic confidentially with me. Please let me know if there are any questions. Thanks!

    Regards,

    Paul Kundmueller
  • I sent you a private message, too.

    Any word about the power down considerations for the AM335x?

    Thanks,
    Jesse
  • Some more additional information:

    We scoped the BAT and USB input pin as well in suspect that a wakeup condition was being triggered. We saw that there is a voltage on the battery input pin even if there is no battery connected. Does this mean the battery charger is on?

    Note: we've shorted the USB input pin straight to ground contrary to our schematic.

    Thanks! 

  • Hi guys, hoping if I can get some assistance.

    Adding some more info.

    It seems that upon shutdown, the PMIC is detecting a wakeup condition.  Specifically, at the AC input even if that input was never removed. When we call the shutdown command, the PMIC will shutdown (SYS_5V included) for 1 sec then reboot. Upon reboot, we read 0x02 on the interrupt register (0x02) signaling a status change on AC power. This maybe causing the improper shutdown sequence and the unintended reboot after 1 sec.

    (Note: nINT is pulled up to LDO4 by a 120k Ohm resistor)

    (Note: nWAKEUP is pulled up to LDO1 by 4.7k Ohm resistor)

    Scoping the AC input, though, we see no change, but only a constant 5V. Which leads us to suspect the BAT input messing with the AC detect during shutdown (scope image in the post above). We've tried pulling down the BAT input with a 1k Ohm resistor (scope image below) to lessen the occurrence of the unintended reboot, but the problem is still there.

    (Note: USB input is to GND; BAT input is pulled low in this screenshot**)

    Thanks,

    Jesse

  • Hi Jesse,

    The SYS voltage should not be falling when you de-assert PWR_EN. Are you using the latest SDK? When the 'shutdown -h now' command is executed, what information is it sending to the PMIC? Do you know if the OFF bit is being set to 1 when the ‘shutdown –h now’ command is being executed? If so could you try to manually write this to ‘0’ to see if you can still see the SYS voltage falling. I think by setting the OFF bit to ‘0’, it is causing an improper power down sequence.

    As for the AM335x sequencing, the only major concern for power down is that voltage difference between the 1.8V analog supply rails and the 3.3V analog supply rails never exceeds 2V (see below note). As long as this requirement is not violated then there is not an issue with power down sequencing. However, I would like to continue to investigate this some more so we can understand why this is happening on your board. Let me know if there are any questions. Thanks!

    Excerpt from AM335x datasheet


    Excerpt from TPS65217 datasheet.


    Regards,

    Paul Kundmueller

  • Hi Jesse,

    Sorry wanted to clarify. I think by setting the OFF bit to '1', it is causing an improper power down sequence' . I think if the OFF bit is set to '0' and the PWR_EN bit is deasserted then there shouldn't be an issue with power down sequencing.

    Regards,


    Paul Kundmueller

  • Hi Paul,

    I appreciate the help.

    I'll confirm with our software team about what's being sent to the PMIC during shutdown routine, since I don't have access to the source code.  I'm a bit confused, don't we want the OFF bit to be set to 1 then deassert PWR_EN to enter OFF state? As per the datasheet, keeping the OFF bit at 0 then deasserting PWR_EN will put the PMIC to SLEEP state.

    But, I think I've already done this test in my Feb. 10 reply to you.  Checking PMIC register 0x0A I am reading 0x08, OFF Bit = 0. Then I physically pulled the PWR_EN pin low and got the following sequence:

    [DCDC2 - VDD_MPU; DCDC3 - VDD_CORE] --> [3.3V_LDO2] --> [1.8V_LDO3; DCDC1 - VDDS_DDR]

    SYS_5V does not drop and this time 1.8V_LDO1 (VDDS_RTC) did not shut down.  And 3.3V_LDO4 only dropped down to around 2.3V. (SLEEP state, except LDO4?)

    Out of curiosity, today I set the PMIC register 0x0A to 0x88, OFF Bit = 1. Then pulled PWR_EN low and saw this on SYS_5V while PWR_EN was held low:

    I'll work on getting the shutdown sequence in this state.

    Thanks,

    Jesse

  • I'm really concerned about the interrupt seen on nINT as shown in the scope screenshot above. Reading the interrupt register after the unintentional reboot, we see 0x02, or a change in AC status. What could be the cause of this if AC input is always 5V on the scope?
     
    Just realized today that our AC input voltage rail is also hooked up to USB1 VBUS and USB0 VBUS (through a switch IC). Taking note from other threads about beaglebone's random reset issue, I removed the shorting resistors going into SoC's USB0 and USB1 VBUS, but still the same symptoms. I thought maybe this could be the source of the nINT interrupt.

  • We recently tested shutting down the system with the SEQDWN bit of the SEQ 6 register. Now, we were able to keep SYS_5V on during the shutdown sequence.

    We did the following steps:

    1. Set Status Register OFF bit to 1. (To enter OFF state when SEQDWN bit is asserted) (Reg: 0x0A Value: 0x80)

    2. Assert SQDWN bit to trigger a power-down sequence. (Reg: 0x1E Value: 0x02)

    We've only scoped LDO4 and LDO1, but it seems power down sequence is followed.  However, a few questions:

    1. Why does LDO4 (3.3V) only drop to around 2.5V instead of 0V?

    2. Why doesn't LDO1 drop the same time as SYS_5V? (LDO1 is set on default strobe 15 to go down with SYS_5V)

    3. What could be the reason that we are still getting an unintentional reboot after around 1 sec after SYS_5V drops?

  • Paul Kundmueller said:
    The SYS voltage should not be falling when you de-assert PWR_EN.

    This is incorrect. When the OFF-bit is set, at the beginning of the powerdown sequence, at the same time PGOOD is deasserted, the TPS65217 unconditionally switches the power path to battery power, even if no battery is present. This causes BAT to become equal to SYS voltage (as has also been observed) and from that moment on, during the entire sequenced powerdown, the system is running entirely on the capacitors on SYS.

    Paul Kundmueller said:
    I think if the OFF bit is set to '0' and the PWR_EN bit is deasserted then there shouldn't be an issue with power down sequencing.

    This causes the system to enter RTC-only mode, which was defeatured by TI.

    Jesse Caparangca said:
    Why does LDO4 (3.3V) only drop to around 2.5V instead of 0V?

    Looks like a serious leakage path from somewhere into LDO4? The BeagleBone Black has such a problem for example (click to zoom):

    3V3A is LDO4, 3V3B is provided by a separate LDO enabled by 3V3A. What happens is that before 3V3A can fall low enough to disable the separate LDO, sufficient current starts flowing from 3V3B into 3V3A to prevent from falling low enough to disengage the LDO. Fortunately since the LDO is powered from the collapsing SYS, the 3.3V supplies have lowered sufficiently by the time the 1.8V supplies are switched off to prevent damage.

    You may want to check your schematic for similar constructions.

    In case you're wondering, 3V3A is seen temporarily leveling off at around 1.4V until strobe 15, this is due to leakage from VDDS into VDDHV. I've posted some analysis a while ago (in this forum, but it was moved), TPS65217 vdds leakage current. Much later I discovered the same issue being mentioned in the AM57xx errata :-)

    Jesse Caparangca said:
    Why doesn't LDO1 drop the same time as SYS_5V? (LDO1 is set on default strobe 15 to go down with SYS_5V)

    I just noticed your timescale... the problem isn't LDO1, it's SYS_5V. The whole sequenced shutdown is normally done in 10ms. It seems to me that SEQDOWN never causes SYS to be disabled, it only does so because finally a reset is triggered in the TPS65217, which makes it power off, wait 1s, power on.

    The situation inbetween where LDO4 is at 2.5V but your 1.8V supplies are off is an extremely unhealthy situation, generously violating the absolute maximum ratings!  I suggest avoiding SEQDOWN at least until you've found what is injecting current into your LDO4-supplied power rail.

  • Hi Matthijs,

    Thank you very much for the helpful information.

    That answers my questions about SYS and BAT behavior.  We have our circuit wired up similar to the BBB, except 3V3B is provided by a DCDC converter enabled by 3V3A and supplied by SYS. I'm guessing the leakage is happening in a similar fashion but, since SYS doesn't drop during a SEQDWN shutdown this could be continuously leaking into 3V3A. We'll avoid this method completely for now. I've been worried about the processor ever since seeing that >2V difference between LDO4 and LDO1.

    With that being said, our regular shutdown routine (ALARM2 asserting PMIC_EN) still leaves us with the same problem of intermittent rebooting when we invoke the shutdown routine.  LDO4 in this case safely drops to 0V because SYS voltage drops.  What could be causing this reset?

    We've seen slight drops in voltage on the PB_IN and nRESET pin of the PMIC even if we have these floating.  I've tried pulling them up to the AC input voltage to prevent the drops but still get the same reset.

     Same behavior on nRESET, 5V drops to about 3.8V on the duration of the reset.

    Our only other suspect for a RESET condition is the PMIC_EN pin shooting up just as SYS drops.

    But this happens regardless of a reboot or good shutdown.

    Other observations we have is that the PMIC nINT pin is sending an interrupt just as SYS drops. When we read the interrupt register after an unintentional reboot it says a change in AC status occurred. So we probed the AC input.  We get some noise 200-400mV short ripples but suppress them with capacitors to still get an unintentional reboot. Datasheet states that the AC input would have to go down to 3.5V(UVLO+offset) before a removal detection occurs and go up to 4.3V for a detection threshold. We thought it could be because of the BAT voltage momentarily rising > 3.5V therefore changing the AC detection thresholds and confusing the PMIC to think that there's a wakeup condition, but since that behavior is normal and occurs on the BBB, we may have to think elsewhere. 

    Maybe you have a suggestion of where else we can look? This problem has been bugging us for a while now.

    We appreciate all the help.

    Thank you very much and best regards,

    Jesse