• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 65 subscribers
  • Views 1558 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.

TPS65950 Starting Issues.

Tony Wilkey
Prodigy 110 points
Other Parts Discussed in Thread: TPS65950

We use the TPS65950 (PMU) with an OMAP2. When our unit is "off" VBAT=2.8 to 3.0V (PMU is in Wait-On state). When we apply power
VBAT rises to 4V and the "START_ON VBAT" event starts the PMU. This works most of the time.

These two conditions seem to prevent or not allow the "START_ON VBAT" event to start the PMU (Wait-ON to active).


Condition one:

If we write the DEVOFF bit to the PMU to shut off. (VBAT=3V and in Wait-on state) The next time we apply power, the PMU does not
turn on when the VBAT voltage rises to 4V? And yes we have that starting event enabled.

Condition two:

Our unit is off and VBAT=3V. We connect a USB cable to the unit and then disconnect the USB cable. (The unit is still off). The
next time we we apply power, the PMU does not turn on when the VBAT voltage rises to 4V?

Does anyone know why either of these conditions prevent the PMU from starting up from the "START_ON VBAT" event?

Thanks,
Tony Wilkey
RELM Wireless.

  • 0
    TI__Genius 10885 points
    Hi Tony,

    From the TRM it looks like the PMIC should transition into active mode around 3.2V, is that what you are observing most of the time?

    I'm not sure why devoff and USB would keep the PMIC from starting up unless the charging scheme is getting confused, does your code update any of the charging registers to values other than default?
  • 0 in reply to Richard Solarski
    Prodigy 110 points
    Yes as long as we never write the devoff bit or do not connect the USB(With the unit off) the PMIC goes active when VBAT rises from 3V to 4V.

    We do not use the charger or change any of the charging registers.

    Regards,
    Tony Wilkey
  • 0 in reply to Tony Wilkey
    TI__Genius 10885 points

    Hi Tony,

    STARTON_VBAT often refers to battery insertion (no supply to presence, then presence to wait-on), but unfortunately I do not have an EVM to experiment with, but I would still expect your insertion of AC or USB supplies to start the PMIC.

    One thing I noticed in some old test procedures I found was they would sometimes write 0x9 to P1_SW_EVENTS when they set the device into off, enabling LVL_WAKEUP, so that could be something to try. While this looks specific to the nSLEEP pin from the register description, there's a possibility it could allow hardware interrupts to bring the device back into active mode.

    Does writing 0x9 instead of 0x1 to the P1_SW_EVENTS register make any difference?

  • 0 in reply to Richard Solarski
    Prodigy 110 points
    Writing 0x9 resulted in the same problem.
  • 0 in reply to Tony Wilkey
    TI__Genius 10885 points

    Well bummer,

    For the rest of our testing can we keep using 0x9 just in case? If we are able to get the correct behavior we can then revert to 0x1 and see if that bit made any difference.

    Can you confirm which mode you are in, and if we cannot get VBAT to work could one of the other starting events work instead? And is the AC insertion event similar to the way you power the PMIC?

    Table 5-11. Starting Events

    Number     Starting Event                                                                 Mode (1)             State Transition
    1                  AC charger insertion                                                             M                   Switch ON
    2                  Main battery insertion and STARTON_VBAT = 1               M                  Switch ON
    3                  PWRON button pressed                                                       M                  Switch ON
    4                  PWRON digital signal high                                                  S                   Switch ON
    5                  RTC alarm                                                                               M                  Switch ON
    6                  Back from stopping event 2 and 3                                      M                  Switch ON
    7                  VBUS detection and STARTON_VBUS = 1                        M                  Switch ON


    Does setting HFLCKOUT_DEVGRP[7:5] = 100, and HFCLKOUT_REMAP[3:0] = 0000 change the behavior at all?

    This might address a clock gating issue mentioned in the errata, and would probably be most applicable to the DEV_OFF issue.

  • 0 in reply to Richard Solarski
    Prodigy 110 points

    We are in Master Mode. Setting HFLCKOUT_DEVGRP[7:5] = 100, and HFCLKOUT_REMAP[3:0] = 0000 Still results in the same behavior as before.

    Our product is designed to use the "START_ON VBAT" event. But because we can't use Devoff to shut off correctly we can get On/Off/On cycles that results in our power switch being in the ON position, but the product is not on. We have a work around that uses the PMIC watchdog to reset the PMIC after 1 second and then we reboot. But this may not me a fix for all conditions. We get occasional reports from our customers that sometimes our product does not turn on the first time and requires another off/on cycle to turn on.

  • 0 in reply to Tony Wilkey
    TI__Genius 10885 points
    Can you confirm that your Rbciauto resistor is > 140 kΩ as well, just to remove it from consideration?
  • 0 in reply to Richard Solarski
    TI__Genius 10885 points
    Hi Tony,

    Does the PWRON button still work?

    Just ran across this note about interrupt handling in OFF state that could be a factor.

    "The interrupt handler has the following limitations:
    • No wake-up interrupts from subsystem modules in OFF state that can turn the device to ACTIVE state"

    And when you set DEVOFF with SEQ_OFFSYNC default to 1, you are shutting down all groups, not just individual subsystems.

    "NO SUPPLY and BACKUP are global states (they are the same for all processor groups).

    ACTIVE, WAIT-ON, and SLEEP are subsystem states (different processor groups can be in different states). Global
    system states are managed through dedicated hardware, while subsystem states are managed by a
    power-management state-machine."
  • 0 in reply to Richard Solarski
    Prodigy 110 points
    We have BCIAUTO connected to ground. Which is recommended when not using the charger.
  • 0 in reply to Richard Solarski
    Prodigy 110 points
    I have tried forcing PWRON low after we write DEVOFF and yes it turns on.

    So you are saying that after we write DEVOFF, the only way to turn on is with PWRON?

    Tony
  • 0 in reply to Tony Wilkey
    TI__Genius 10885 points
    I would expect AC or USB insertion to also turn the PMIC on, unless these require active resources that are being disabled by the broadcast message.

    Since the battery is never being removed after DEVOFF, I'm curious if setting the next address to 00 instead of 63 for the DEVOFF sequence is possible/has any effect, as we might be skipping this state if there is no insertion event.

    Alternatively, we could try leaving some of the resources mentioned in the W2P sequence active to see if there is a dependency on these resources.