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.

AM3354: PMIC_POWER_EN is not asserted on power-up

Part Number: AM3354
Other Parts Discussed in Thread: TPS65910, TPS65218D0, TPS65217

Hi,

My customer reported AM3354 power-up failure when the device is power-off then power-up again.
PMIC_POWER_EN signal from AM3354 is not asserted when the issue happens.
Please see attached excel for details.
AM3354_powerOn_failure.xlsx
I found similar issue reported below E2E, but it was not clear if the issue was understood and solved.
It discussed VRTC and RTC_PORZ timing.
https://e2e.ti.com/support/processors/f/791/t/768660
As you can see the sheet#3 in the attachment, RTC_PORZ is driven to high as soon as VRTC is on in customer’s system.
Does it cause an issue?

Thanks and regards,
Koichiro Tashiro

  • Hi,

    It's recommended to delay RTC_PORz release until the 1.8V RTC supply completely reaches 1.8V. However I see in the schematic the RTC_PORz is connected to 1.8V RTC almost directly. So it's possible for the reset to be released too soon and the RTC domain did not start. Because the RTC domain is perhaps in an unknown state and the PMIC_POWER_EN pin is part of this domain then the result is this signal is not released.

    Note A of the AM335x datasheet (figure 6-2) recommends a delay of at least 1 ms on RTC_PORz for the internal LDO to finish its ramp up. However this also applies to any external supply the system is using to power 1.8V RTC in lieu of the internal LDO. 

    Please test with an RC delay of greater than 1 ms on the RTC_PORz signal.

    Regards,
    Ahmad

  • Hi Ahmad,

    Thanks for your quick reply!

    In customer’s system, RTC is not used, so customer tested below two options:
    a) connect RTC_PORz to PORz. This was recommended in below E2E thread.
    https://e2e.ti.com/support/processors/f/791/t/755784
    b) connect RTC_PORz to VSS(GND). This is recommended in table 2 below document.
    http://www.ti.com/lit/an/sprabn2/sprabn2.pdf

    Both works and the issue disappears. Customer tested with 1 units, and will test other 5 units.
    As option b) is easier for customer, they prefer this option.
    But the table2 also says PMIC_POWER_EN is “No Connect” in case “RTC Feature Disabled”.
    In customer’s system, PMIC_POWER_EN is connected to PMIC PWRHOLD pin. Is this acceptable?
    According to data sheet, Figure 6-2 to 6-5, PMIC_POWER_EN goes high even RTC_PORz is low.
    So it should be OK. Please confirm.
    http://www.ti.com/lit/ds/symlink/am3354.pdf

    And do we have technical explanation why PMIC_POWER_EN does not asserted only in case Off period is ~1.5sec?
    Customer guesses 1.8V_VRTC residual voltage(~0.35V) prevents RTC domain reset properly.

    Thanks and regards,
    Koichiro Tashiro

  • I believe at the point of shutdown is when there will be a difference. Which PMIC are you using with the AM3354? You'll have to check the datasheet since the behavior will depend on the internal state machine, if any. It's usually recommended to follow the user guide written for the PMIC + SoC combination. It will be in the technical documents section of the PMIC product page.

  • Ahmad,

    Customer is using TPS65910.
    I checked PMIC datasheet and below user’s guide.
    TPS65910Ax User's Guide for AM335x Processors (Rev. F)
    http://www.ti.com/lit/pdf/swcu093

    It is not clear how PMIC_POWER_EN (PWRHOLD) makes differences with option b).
    I think PMIC_POWER_EN goes to high at power-up and goes to low at power-down even RTC_PORz is always Low.
    Correct?

    Thanks and regards,
    Koichiro Tashiro

  • On the TPS65910 the POWERHOLD pin triggers the power down sequence when pulled low. In Linux at shutdown a timer in the RTC domain is set which pulls PMIC_POWER_EN low after 1 second (this is the "shutting down in 1 second" message you see in the serial output). If the RTC domain is disabled with RTC_PORz pulled to VSS then I'm not sure how the shutdown mechanism will continue to work.

    Disabling the RTC domain is only for applications not using a PMIC. When using a PMIC it's recommended to follow the PMIC user guide and make no changes. 

  • Ahmad,

    What is recommended PWRHOLD signal connection when RTC is disabled?
    Below user’s guide table 2 just says “No Connect”, but I guess this is AM335x side.
    http://www.ti.com/lit/an/sprabn2/sprabn2.pdf

    PMIC datasheet does not mention anything about it, but it seems PWRHOLD needs to be high to start power-up sequence.

    Thanks and regards,
    Koichiro Tashiro

  • Using any PMIC with AM335x it is expected the RTC domain stays enabled, including TPS65910. Majority of cases it is unnecessary to disable the RTC.

    From Table 2 of the guide you can follow the "RTC Timer Functionality but no RTC-Only Mode" design however RTC_PORz should be connected to PORz and PMIC_POWER_EN should be connected to PWRHOLD.

  • Hi Ahmad,

    Sorry for my late reply.
    I confirmed customer’s usecase.
    - Customer does not use PMIC_POWER_EN at power-down sequence. All power supplies are shut off simultaneously.
    - Customer confirmed the difference between VDDS and VDDSHVx[1-6] during the entire power-down sequence is <2V.
    - This is not preferred way, but acceptable according to datasheet section 6.1.2 Power-down sequencing.

    RTC is not used at power-down, so connecting RTC_PORz to GND should be no problem. Correct?

    Thanks and regards,
    Koichiro Tashiro

  • Hello Koichiro Tashiro,

    Yes it sounds like you're not using the POWERHOLD signal on the TPS65910 and instead using the DEV_OFF bit to control power down. This is acceptable and allows you to disable the RTC on AM3354. My previous reply is still true for other PMICs TPS65217 and TPS65218D0.

    Regards,
    Ahmad

  • Hi Ahmad,

    Thanks for confirmation.
    Customer will take the option b) connect RTC_PORz to VSS(GND).

    Thanks and regards,
    Koichiro Tashiro

  • Hi Koichiro,

    Thank you, it's good we found a conclusion. 

    Regards