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.

AM4372: Simplified power sequence with TPS65216

Part Number: AM4372
Other Parts Discussed in Thread: TPS65216, TPS65218, TPS65250, TPS65910

Dear Champs,

My customer will use TPS65216 for AM4372. Is is possible to use simplified power sequence with TPS65216?

As I know, the simplified power sequence is not for PMIC as PMIC is handling power sequence, right? I see below e2e and think simplified power sequence can not be used with any PMIC, right?

https://e2e.ti.com/support/archive/internal/int_sitara_am335x/f/425/t/377973?tisearch=e2e-sitesearch&keymatch=AM437x%2525252525252520AND%2525252525252520simplified

Thanks and Best Regards,

SI.

  • The default power sequences are designed for the SoC and you can not change the sequence. Do not try to follow any "RTC disabled" sequence. 

    Follow the TPS65216 User Guide for Sitara please. 

  • Hi,

    Thanks for this information. 

    Do you mean any "RTC disabled" sequence can not be worked with TPS65216?

    Could you please explain details?

    When TPS65216 will be used with AM4372, RTC mode should be enabled? 

    When I checked TPS65216 UG for Sitara you mentioned, there was "Figure 5. Power Rails for RTC Domain" in the document, but I could not find any statement this is mandatory, and I could not find any restriction with RTC disabled.

    I think there is no issue in the power sequencing even with RTC Feature Disabled if RTC domain connected as below table(RTC Feature Disabled).

    My customer will use TPS65216 to supply power to AM4372 and they will not use RTC feature of AM4372.

    I need to confirm if TPS65216 can be used with AM4372 RTC disabled and power sequencing RTC disabled in their HW.

    Please check this again and let me know details if it is not possible.

    Thanks and Best Regards,

    SI.

  • Follow the PMIC user guide. If you're using Linux the RTC can be disabled in the device tree or just don't use it. 

  • Thanks for your immediate response, but I'm still confusing.

    They will use TI-RTOS.

    Do you think it would be an issue to use TPS65216 with RTC disabled HW configuration in above Table 3?

    Do you mean the default power-up sequencing of TPS65216 is not matched with AM4372's power-up sequencing with RTC disabled and should be modified for it?

    When I checked the document(http://www.ti.com/lit/ug/spruip2/spruip2.pdf) you mentioned,

    it seemed the default power-up sequencing of TPS65216 is LDO1 -> DCDC3 -> DCDC4 -> DCDC1 -> DCDC2 as below.

    And, I also found each power pins of TPS65216 are allocated as below.

    And, it seemed these are matched with power-up sequencing with RTC disabled  described in Figure 5-7 of AM4372 datasheet.

    I could not find any issue to use TPS65216 for AM4372 power-up sequencing with RTC disabled. Please let me know if there is an restriction to use TPS65216.

    My customer started HW layout design using TPS65216 and they will not use internal RTC of AM4372.

    We should request to change TPS65216 to other PMIC like TPS65218 immediately if there is any restriction or issue.

    Their SW will be TI-RTOS.

    Thanks and Best Regards,

    SI.

  • If the customer does not plan to use the RTC that is OK, but why must the RTC subsystem be hardware disabled?

  • There is nothing special reason to make RTC subsystem be hardware disabled. They just have no plan to use the internal RTC.

    What is your recommendation in this case? 

    My customer also will use IO as 3.3V only.

    Do you think 'Power Sequencing with RTC Enabled with 3.3V(Figure5-4)' is more efficient than 'Power Sequencing with RTC disabled with 1.8V and 3.3V(Figure5-7)'? Could you please explain details?

    Is there any issue using 'Power Sequencing with Dual-Voltage IOs Configured as 1.8V, 3.3V' although there is no 1.8V IO?

    Thanks and Best Regards,

    SI.

  • Hi Sung-IL,

    Sorry for the confusion on this topic and I'll try to answer all your questions. Most important - the default PMIC sequence is compatible for all AM335x, AM43x, and AMIC parts so no modification is necessary. The "RTC disabled" options in the datasheet are for discrete IC power solutions and not meant for our PMIC solutions. The table in the schematic checklist is also for discrete ICs only and not meant for the PMIC solutions. 

    • Do you think it would be an issue to use TPS65216 with RTC disabled HW configuration in above Table 3?

    There are a few impacts to software. 1) The RTC subsystem is needed to drive the PMIC_POWER_EN pin to enter suspend to RAM mode and then receive wake interrupts on the ext_wakeup pin. 2) There is an internal 32k clock source, however if the external 32k OSC is used then the RTC SS is needed. 3) Our Linux SDK expects the external 32k crystal + RTC domain enabled by default so disabling the RTC SS will cause it to hang during boot (example1, example2, example3). You can see the TRM section "RTC Integration" for more information on signals going to or coming from the RTC subsystem.

    • Do you mean the default power-up sequencing of TPS65216 is not matched with AM4372's power-up sequencing with RTC disabled and should be modified for it?

    The "RTC disabled" connections are meant for discrete IC power solutions. The power sequence is programmed in OTP and cannot be permanently changed. Any changes to the sequencing registers will be lost since they automatically reset to defaults.

    • Power sequence impact on power efficiency?

    RTC does not use much power, it is only important if your application requires RTC time to be kept for years while on battery. However, do you have additional questions on power consumption?

  • Here is an example in RTOS that might be impacted. In the following file <pdk_dir>\packages\ti\board\src\evmAM437x\evmAM437x.c see line 200, the PRCMModuleEnable call for RTCSS might fail.

  • Thanks for your kindly explanation with details.

    I have one more question.

    I understand your concern is mainly focusing on the SW modification.

    Then, if customer modify SW correctly by themselves, do you think any other issue to use "RTC disabled" power-up sequencing with PMIC?

    With 'RTC disabled', there is only power up sequence with dual IO, but my customer is using only 3.3V IO.

    I also want to check if it is OK in the power-up sequence with dual IO when there is no 1.8V input to VDDSHVx.

    My customer is worrying that unnecessary RTC circuit may causing side-effects and I remembered there have been no issue with RTC disabled circuit in AM335x. It is first time for me to support AM437x, and want to make clear on this issue. Please understand this.  

    Thanks and Best Regards,

    SI.

  • The "RTC-only mode" connection recommendations apply to the TPS65216. You do not need to use the RTC and you do not need to use the RTC-only mode. The other columns do not apply. 

    1. The PMIC requires its PWR_EN pin to be pulled high within a few seconds to stay on, otherwise the supplies will turn off. By default the SoC drives this signal through the PMIC_POWER_EN output.
    2. To shut down the SoC will drive the PWR_EN pin low to power down the PMIC supplies. That is normally done on the SoC through RTC APIs.

    If the customer used "RTC disabled" recommendations for AM335x what PMIC did they use? Do they stay always-on instead and never shut down?

    The power up sequence with dual voltage IO applies to single voltage IO too. Any VDDSHVx at 3.3V can be connected to DCDC4 and any VDDSHVx at 1.8V can be connected to LDO1. No problem if all your VDDSHVx are at 3.3V.

  • Thanks for your kindly response.

    Normally most of AM335x customers are using TPS65250 or TPS65910, and most of their system is being stayed long and shut down by ground PWR_EN pin of PMIC.

    The below is my customer's implementation for PWR_EN of TPS65216, and it would be very helpful if let me know your opinion.

    Thanks and Best Regards,

    SI.

  • The 5V pull-up is acceptable for an always-on use case. I'm not sure about Q1, you do not want to invert the PMIC_PWR_ON signal from the SoC.