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.
Part Number: TPS65218D0
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?
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)
Thanks & Best Regards,
Find the right power solution for your processor or FPGA. Visit www.ti.com/SoCPower today!
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Brian Berner:
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.
In reply to Matthias Fuchs30:
Matthias Fuchs30When 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.
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?
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:
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?
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.
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.
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.
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.