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.

TPS65218D0: AM335x board shutdown problem

Part Number: TPS65218D0
Other Parts Discussed in Thread: BOOSTXL-TPS65218

Hi,

we upgraded a stable custom AM335x design from TPS65217D PMIC to TPS65218D0. The boards boots fine ti linux kernel 4.14.79 from processor sdk. Rebooting via "reboot" is fine. But trying to poweroff just reboots the board. I found that this - or something similiar - was an issue with prior silicon of the PMIC. But we have the latest - chipid is 5.

Design is based on http://www.ti.com/lit/ug/slvuaa9a/slvuaa9a.pdf.

I posted this issue here https://e2e.ti.com/support/processors/f/791/p/821927/3042426

To test poweroff function I finally added a test funtion in our bootloader to minimize the software influence on the issue.

I ended up playing with the AC_DET pin. My setup supplies our board via 5V USB power. This pulls down AC_DET pin - as intended. When I remove the external 5V our board runs from battery and AC_DET is pulled high. I noticed that the board goes to OFF state after calling poweroff command when AC_DET is high and reboots when AC_DET is low. From the datasheet I expected that the PMIC shuts down independant of AC_DET. Just a falling edge (!) on PB or AC_DET should do the wakeup. But here a low level on AC_DET does not allow shutdown but causes a reboot.

This looks strange. Or did I misunderstand the AC_DET pin?

Any hint?

Regards,

Matthias

  • If you refer to TPS65218D0 datasheet, page 47, the global state diagram for the PMIC (Figure 5-34. Modes of Operation Diagram) says that the device will transition from the OFF state towards the ACTIVE state when:

    VIN_BIAS > (VUVLO + hysteresis) & (PB (falling edge) || AC_DET (falling edge) || PWR_EN = high)

  • Hi Brian,

    right. But PB and AC_DET are static in my case! No edges! And PWR_EN has been switched off by the CPU (AM335x RTC_PMIC_EN) to go into OFF state.

    When AC_DET is inactive I cannot go to OFF and when AC_DET is active the PMIC starts up my system again. This does not fit to the state diagram.

    Matthias

  • Matthias Fuchs30 said:
    When AC_DET is inactive I cannot go to OFF and when AC_DET is active the PMIC starts up my system again.

    I do not understand this sentence, and it appears I did not understand your problem statement in the original question either. Your definition of "active" and "inactive" are not clear to me. 

    Maybe you can draw a timing diagram of what is happening, or capture some signals on an oscilloscope to show the issue.

    In some datasheets, the phrase "edge detection" is mis-used. For all PMICs that I work with, it is looking for an edge but the circuitry used is actually "level detection". The device is looking for a level at a certain point in the state machine (e.g. a timer has expired, the level was high and is now low)

    If you read the next paragraph of the datasheet: "To exit OFF mode VIN_BIAS must exceed the UVLO threshold and one of the following wake-up events must occur:

    • The PB input is pulled low.

    • THE AC_DET input is pulled low.

    • The PWR_EN input is pulled high.

    To enter OFF state, ensure all power rails are assigned to the sequencer, then pull the PWR_EN pin low."

     

    AC_DET is active-low, PB is active-low, and PWR_EN is active high.

    When AC_DET is inactive (logic-level is High), it does not determine the state of the PMIC at all.

    Similarly, when PWR_EN is active (logic-level High), AC_DET is meaningless.

    The only thing that matters when transitioning from ACTIVE to OFF (or SUSPEND) state is that PWR_EN toggles from High to Low.

    If you can verify PWR_EN is low and AC_DET/PB are static, then there are only two possibilities:

    If you are not in the OFF state here, then you must be in the SUSPEND state.

    This would mean that DCDC1, DCDC2, DCDC3, DCDC4, or LDO1 is disconnected from the sequencer.

    If you are very certain of your test setup and believe the State Machine is incorrect, I will need to review a scope shot/timing diagram showing these signals (PWR_EN, AC_DET, PB, PGOOD) to debug further.

  • Hi Brian,

    back from vacation ...

    My sentence was wrong - sorry. When AC_DET is inactive (high) I can go to OFF and when AC_DET is permanently active (low) the PMIC starts up my system again.

    For me that means you never make it to OFF state when AC_DET is low all the time and I see the PMIC going from PRE_OFF to WAIT_PWR_EN again. Is this right?

    I interpreted the state diagram in the way that AC_DET is checked for a high to low transition while in PRE_OFF or OFF to start up again through WAIT_PWR_EN. So when AC_DET is permanently low

    the PMIC will wait in PRE_OFF or OFF.

    How can I power off my device while AC_DET is low because my external power supply is connected?

    Regards,

    Matthias

  • Matthias, 

    Right now I think it is more a question of patience and understanding than anything.

    If AC_DET is permanently low, then PWR_EN is used to transition between states.

    Let us start at the beginning:

    • external power supply is turned on and powers the PMIC (AC_DET = low, PWR_EN = low)
    • PMIC turns on and automatically sequences on all the rails
    • PWR_EN is set high within 20 seconds so all rails stay on
    • PWR_EN is set back to low to power-down all rails (DCDC5/6 are FSEAL dependent)
    • At this point, nothing will happen again until PWR_EN is set high (because AC_DET = low permanently and you external supply is constant)
    • As long as nothing else changes, toggling PWR_EN will continue to transition between ACTIVE (PWR_EN = high) and OFF (when PWR_EN = low) states ad nauseam.

     

  • Hi Brian,

    you are right. This is my initial power on (1:Vbias, 2: AC_DET#, 3: PWR_EN, 4: VDCDC6):

    This is as expected. Without AC_DET#=low I have to assert PB=low - just for reference.

    This is what happens with AC_DET#=high when the AM335x deasserts PWR_EN:

    So PWR_EN goes low and so all rails go off. Fine!

    Now the problem: I want to poweroff the system by setting PWR_EN to low while AC_DET#=low:

    So same as with AC_DET#=high, but after 500ms systems starts again. I must say that the PMIC behaves as expected due to PWR_EN activation.

    But where does this come from and how can this different behavior be caused by AC_DET# state?

    Matthias

  • Matthias,

    I think I may know what you are seeing now, but your use of the term "AC_DET#" is confusing me somewhat. The pin is simply named AC_DET, so I assume you can only measure the pin itself and not the inverse of the pin.

    Regardless, the way I am setting PWR_EN low is different than the way you are controlling PWR_EN:

    When I toggle PWR_EN on the BOOSTXL-TPS65218 board, I am physically toggling a switch. Therefore, when I say PWR_EN == low, I mean that it has toggled from high to low and stays low. In the scope shots you have provided, PWR_EN is toggled low for a short period of time and then released.

    I cannot say for sure exactly what is happening in your system, but you should monitor the PGOOD and PGOOD_BU pins to understand the signals the PMIC is giving to the processor during all of your test cases. The PMIC provides signals to the processor and the processor controls the PMIC. 

    In my testing, there is no processor and I am controlling PWR_EN pin myself.

  • Brian,

    you are right. I measured on the AC_DET pin. I only added the '#' marker for my better understanding: low means external power detected.

    The PMIC is connected to a AM335x CPU acc. SLVUAA9A

    I made to measurements with AC_DET=high and AC_DET=low (ch1: Vbias, ch2: PWR_EN, ch3: PGOOD_BU, ch4: PGOOD with ext. pullup).

    AC_DET=high -> PMIC stays in OFF:

    AC_DET=low -> PMIC goes to ACTIVE again:

    I have no idea why PWR_EN goes high again and follows that ugly waveform. I compared PWR_EN to our prior design based on the TPS65217D.

    The TPS65217D does not show the problem and PWR_EN stays low and does not show the ugly lapse.

    And what's that ugly lapse on PGOOD_BU? This might be a problem.

    So I think the problem might be related to TPS65218D0 with our connection to the AM335x. The above design guide seems clear to me but perhaps we made it wrong.

    Is there anybody who known about the connection of these two parts?

    From the AM335x datasheet I took that the VDDS_RTC (PMICs DCDC6) ramp is followed by enabling PWR_EN. But the PGOOD_BU waveform could be a problem.

    Matthias

  • Matthias,

    In order to debug this issue further I think we will need to see the schematic for your design showing the connections between the TPS65218D0 and the AM335x. Although you said you followed the Powering the AM335x, AM437x, and AM438x With TPS65218 User's Guide, it is clear that something is not working as expected and we will need to see the schematic to verify the wiring.

    The ugly ramp down on PWR_EN and PGOOD indicate that nothing is pulling the line low. Rather, it is drifting down from the logic high voltage to 0V. 

    I will re-assign this question to the processor team so that someone from the AM335x side is also looking at it, and I will still get notifications.

  • Hi Brian,

    I pasted some relevant parts from our schematic to a pdf file. I cannot post the full schematic in this public forum. Please give me a hint if something is missing.

    Regards,

    Matthias

    PMIC_Issue.pdf

  • Matthias,

    2 things I noticed:

    1. PMIC_PWREN has a 100k pull-down to GND and in the processor this is a push-pull output that is referenced to RTC domain
    2. PGOOD_BU is the other signal that is ramping down slowly, which is referenced to 1V8_RTC (as opposed to PGOOD which is pulled up to 3V3_LDO)

    In my opinion, the reason these signals are not behaving as expected is because the DCDC5 and DCDC6 rails are shutting off when PWR_EN initially goes low.

    The reason for this would be that FSEAL=0b.

    If you are going to use the DCDC5/6 rails, then FSEAL=1b is the correct setting (even if you are not using a backup battery at the CC pin. SYS_BU receives power from IN_BU, which is still a valid power supply, but when PWR_EN goes low it is turning off the DCDC5/6 rails. This is not ideal because it causes the RTC domain to lose power.

    Please set FSEAL=1b during initialization and re-test your system.

  • Brian,

    I removed the PWREN 100k pulldown. Makes no difference. But right, not needed.

    I invested in setting FSEAL=1. I added some code in U-Boot to get the bit set. This did not work in the first step as expected. FSEAL stuck low.

    Then I supplied about 3V generated from VSYS by a resitor divider and a 4u7 buffer cap to the CC pin. Now I can set FSEAL and I can poweroff the PMIC!

    From the PMICs block diagram and manual I would say that only one of IN_BU and CC is neede and CC may be grounded. Why can't I set FSEAL without CC supplied?

    Do I really need DCDC5/6 enabled all the time?

    I will habe a look at the ramps next.

    But at least there is some light at the end of the tunnel.

    Matthias

  • Matthias,

    Looking at some documentation on the AM335x connections, it appears that VDDS_RTC can be part of the 1.8V Analog & I/O domain, along with VDDS, VDDSHVx (1.8 V), and a handful of other rails.

    As a result, there are potentially 3 ways to avoid this issue:

    • Hardware + Software fix - what you are doing now, i.e. provide power to CC from main VSYS rail (through a voltage divider) and set FSEAL=1b to keep DCDC5/6 on during the shutdown
    • Software fix - Instead of going to the PMIC's shutdown state, enter the SUSPEND state of the PMIC. Before entering the shutdown state, the code needs to disable DCDC6 from the sequencer (in the SUSPEND state, the PMIC datasheet says "DCDC5..6 = seq. / FSEAL dependent") by setting SEQ5 (reg. 0x24) to 0x02. This should keep DCDC6 on and powered from SYS_BU (IN_BU) instead of requiring a valid voltage on the CC pin
      • There is another requirement that DCDC1 = ON || DCDC2 = ON || DCDC3 = ON || DCDC4 = ON || LDO1 = ON to enter the SUSPEND state, but it's possible that there is already a Linux driver patch that keep DCDC3 on for DDR power in the SUSPEND state

    • Hardware fix - change the power supply for VDDS_RTC from DCDC6 to LDO1 (also providing 1.8V). PWR_EN will still be powered from 1.8V and the power will still be available so that it can set PWR_EN = high within the 20s timeout window

    At the end of the day, I think the issue is that your design does not require DCDC5/6 because it is operating in an always-on scenario and not being powered from the CC supply. However, the AM335x connections shown in the TPS65218D0 User's Guide don't articulate that VDDS_RTC doesn't need to be powered from the RTC domain of the PMIC. 

  • Brian,

    thanks for clarification and assistance. We will check which way to go.

    Best regards,

    Matthias