• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 8 answers
  • Subscribers 64 subscribers
  • Views 1265 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TPS65910: PWRHOLD timing

Hirotsugu Kobayashi
Mastermind 9540 points
Part Number: TPS65910
Other Parts Discussed in Thread: AM3352

Hi, team.

We are developing a system using AM3352 and TPS65910.
PWRHOLD is controlled from the outside and turned ON / OFF.
LDO and DCDC do not turn off for 1 second from the first PWRHOLD toggle. Why is that?
Are there any restrictions on the input timing of PWRHOLD?

  • 0
    TI__Mastermind 30310 points
    Please refer to pages 40 and 41 in the TPS65910 datasheet.

    Figure 5-4 shows the PWRON Turn-On/Turn-Off timing, where tdONPWHOLD is the critical timing parameter that determines the "minimum active time" of the PMIC.

    tdONPWHOLD: delay to set high PWRHOLD signal or DEV_ON control bit after NRESPWRON released to keep on the supplies

    Table 5-5 shows that this time is 984 ms.


    If the PWRHOLD pin has ~1s to bet set high, then any toggling before the timer has expired will be ignored.
  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply.

    Look at the waveform that was attached in the first post. After the 984 msec timer has expired, the device can be turned off. If the device is turned on again within several hundreds of milliseconds, it can be turned off within 100 msec, so that it looks like the 984 msec timer has still expired. Then, if the device is turned off after being kept active for several tens of seconds, the 984 msec timer works again.

    Why is the device turned off before the 984 msec has passed after the device is turned on?

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points
    Daisuke-san,

    It sounds to me that you are entering two different states:
    SLEEP - transitioning from ACTIVE to SLEEP can happen quickly, without restarting the 984ms timer.
    OFF - transitioning from SLEEP to OFF or from ACTIVE to OFF, then back from OFF to ACTIVE state will restart the timer.
  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply.

    The DEV_SLP bit is never set to 1 by software. How does the device transition to the SLEEP state?

    The data sheet describes:

     "The SLEEP state can be controlled by programming DEV_SLP and keeping the SLEEP signal in the active polarity state, or it can be controlled through the SLEEP signal setting the DEV_SLP bit to 1 once, after device turn-on."

    I guess the device transitions to the SLEEP state by the following sequence. Is my guess correct?

     1) When the SLEEP signal is kept in the active polarity state by the programmable PD when the device is turned on, the DEV_SLP bit is set to 1.

     2) When the device is turned on by the PWRHOLD signal being high, the PWRHOLD rising-edge interrupt flag is activated (PWRHOLD_IT = 1 in INT_STS_REG register).

     3) When the device is turned off by the PWRHOLD signal being low, the PWRHOLD rising-edge interrupt flag is cleared (PWRHOLD_IT = 0 in INT_STS_REG register).

     4) When all the interrupt flags are inactive, the device transitions to the SLEEP state.

    However, if my guess is correct, I can't understand how the device transitions to the OFF state. How does the device transition to the OFF state?

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points

    Daisuke-san,

    Daisuke Maeda said:
    The DEV_SLP bit is never set to 1 by software.

    What software are you running? The Linux kernel provided by TI? It is possible that a command written into the Linux kernel writes DEV_SLP=1b or it is included in the initialization sequence without being explicitly named in the function being called. If you are using the TI Linux kernel, the software team can help you determine which states you are entering at the system level.

    The requirements for entering SLEEP state are explained on page 47 of the TPS65910 datasheet, and also shown in this logic circuit on page 46 (part of Figure 6-1).

  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply. Sorry for my late reply.

    This behavior is observed on our customer's board. The customer probably uses a 3rd-party OS, and DEV_SLP may be set by the OS. However, the waveform (yellow trace) that was attached in the first post shows, the device is turned off by the PWRHOLD signal being low every time. So that, the device should transition to the OFF state instead of the SLEEP state.

    Can the device transition to the SLEEP state by the PWRHOLD signal being low?

    Is there any other reason why the device turned off before the 984 msec has passed after the device is turned on?

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points
    Daisuke-san,

    I will need to test this in the lab on the EVM to show you the results. I will try to reply with answer and scope shots early next week.
  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply.

    I will wait for your update.

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points

    Daisuke-san,

    As you can see, I get same results as your original test in the lab. For approximately 984ms after NRESPWRON is set high, a change in the state of PWRHOLD is ignored. After approximately 984ms, any time PWRHOLD toggles from high to low, the TPS65910 will transition from the ACTIVE to the OFF state immediately.

    This scope shot, taken from a different perspective (nINT1 on Channel 4), also confirms my original reply to your question: The PWRHOLD pin is ignored for 984ms because the tdONPWHOLD timer has not expired. This scope shot matches the timing of tdONPWHOLD, as shown on Figure 5-4. PWRON Turn-On/Turn-Off on page 40 of the TPS65910 datasheet.

    As soon as the tdONPWHOLD timer ends (approximately 984ms), any toggle on PWRHOLD will transition the device to the OFF state. PWRHOLD is only a condition for transitioning from ACTIVE to OFF.

    The DEV_SLP bit is a condition for transitioning to the SLEEP state, but as you can see in my setup the DEV_SLP bit == 0b

    Therefore, the PMIC has never transitioned to the SLEEP state, and in both of our tests the PWRHOLD pin going low sends the device into the OFF state after the tdONPWHOLD timer ends.

  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply.

    All issues are not clear. It is observed on our customer's board that the tdONPWHOLD timer works again when the device is turned off after the device is kept active for several tens of seconds.

    What are the conditions for the tdONPWHOLD timer to work again?

    What is the time defined for the tdONPWHOLD timer to work again after the timer ends?

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points
    Daisuke-san,

    What is the state of the POWER_ON pin during your testing?

    If the POWER_ON pin has been toggled low, the first falling edge of PWR_HOLD will cause a Reset, the first rising edge of PWR_HOLD will power-on the system, then PWR_HOLD toggles after this will be ignored until the POWER_ON pin is set high again.
  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply.

    The PWRON pin is unconnected and is pulled high by the Programmable PU (default).

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points

    Daisuke-san,

    The User's Guide for powering AM335x with TPS65910Ax does not mention the Programmable PU for the PWRON pin.

    In the system block diagrams (Figure 1 and Figure 2), it shows an external pull-up resistor connected to PWRON.

    It sounds like this recommendation in the AM335x documentation has not been implemented in your design.

    If this pin is left floating and the internal pull-up is not enabled on the TPS65910A3 OTP variant of the device, then this floating input could be the reason for your issue.

  • 0 in reply to Brian Berner
    TI__Mastermind 30310 points
    Daisuke-san,

    On my EVM, I see that the PWRONP bit (bit 5 of PUADEN_REG reg. 0x1C) is set to 1b by default to enable the PWRON pull-up for TPS65910A3.

    However, the same 1s delay will go into effect if the DEV_OFF bit is set to 1b in DEVCTRL_REG (Reg. 0x3F). The device will transition into the OFF state, and when PWRHOLD is toggled it will not take be able to turn off the regulators for approximately 1s.

    This would look the same as during the first power-up sequence because it is essentially repeating the process over again.

    The DEV_OFF bit resets to 0b automatically, so you might not notice if it got set by the software by accident. You need to check to see what happens on the I2C lines just before PWRHOLD goes low for the first time in the scope shot you provided.
  • 0 in reply to Brian Berner
    Guru 20215 points

    Hi Brian-san,

    Thank you for your reply.

    The TPS65910x Schematic Checklist (Rev. B) describes that the PWRON pin can be floated if it is never used.

    Could you tell me about the conditions for the tdONPWHOLD timer to work again?

    The tdONPWHOLD timer seems to stop working once it ends because VDAC and VDD2 turn on and off every time PWRHOLD is toggled. After the device has been kept active for a while, the tdONPWHOLD timer seems to work again because VDAC and VDD2 keep on when PWRHOLD goes low.

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Mastermind 30310 points
    Daisuke-san,

    The same 1s delay will go into effect if the DEV_OFF bit is set to 1b in DEVCTRL_REG (Reg. 0x3F). The device will transition into the OFF state, and when PWRHOLD is toggled it will not take be able to turn off the regulators for approximately 1s.

    This would look the same as during the first power-up sequence because it is essentially repeating the process over again.

    The DEV_OFF bit resets to 0b automatically, so you might not notice if it got set by the software by accident. You need to check to see what happens on the I2C lines just before PWRHOLD goes low for the first time in the scope shot you provided.