• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 1478 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.

TPS65217: Query on Dynamic Power Path Management (DPPM)

sanchayan maity
Expert 1810 points
Part Number: TPS65217


I am using Beaglebone which has the TPS65217 PMIC and using it's battery charging capability. AC power is used and battery is charging correctly. I use the default settings except for setting the charger enable bit in CHGCONFIG1 and the battery is a Lithium Ion battery. However, on removing of AC power it was not being powered from battery which I expected it would. I then set the DPPM bit in CHGCONFIG0 register and it seems to work then. However, this is strange since CHGCONFIG0 register is suppose to be read only.

From my reading of Section 8 of the datasheet, I expected the switch between AC and battery power to work without any special setting or do I miss something?

Also, on Page 49 of datasheet, it says that if the NTC type bit is set, it is for 10k and if not set, it is for 100k. However, on Page 33 it says that for 100k NTC, NTC type bit should be set. From my testing, I have found the former to be correct.

Can someone clarify the above? Thanks.

  • 0
    TI__Mastermind 30310 points
    The hand-off from AC power to BAT power should be automatic.

    However, when battery power is the only available power a push-button press (toggle hi-lo-hi on the PB_IN) pin is required as a wake-up event. It is possible the PMIC is in the SLEEP or OFF state and requires a PB press to wake-up the system.

    I do not believe writing to the DPPM bit in CHGCONFIG0 has any effect (because it is Read-ONLY as you mentioned) and your results may have been coincidental. It is possible other registers were also over-written in addition to CHGCONFIG0 that caused you to see these results.


    If pressing the push-button (PB_IN toggle) does not work, I would need more info to debug: You will need to re-test the removal of AC power and capture your results on an oscilloscope.

    You only need to measure 3 voltages (AC, BAT, and SYS pins) but you can use the 4th channel of the scope to monitor PGOOD or another rail (such as LDO1) to provide more info.
  • 0 in reply to Brian Berner
    Expert 1810 points
    The battery is powered at 3.9V and BB is powered by AC. On turning AC power off, I expect the BB to be powered by battery with the dynamic switch over happening transparently, but, the BB seems to be powered off on removing AC power. I have to manually push the power button to turn it on again using the battery. Is something more required for the switch over to happen? The datasheet does not really clear much here.
  • 0 in reply to sanchayan maity
    TI__Mastermind 30310 points
    When I test on a TPS65217CEVM, removing AC power results in an automatic switch-over to BAT power (SYS voltage drops from 5V (AC) to 3.9V (BAT).

    You will need to provide a scope shot of the issue occurring for me to continue to debug this issue.
  • 0 in reply to Brian Berner
    Expert 1810 points
    I checked the SYS_5V pin coming on the expansion header of Beaglebone on Pin 7/8. It shows 5V when connected to AC and 4.1V when connected to battery. The Beaglebone powers off somehow when I shut off AC power. Perhaps it receives a power down signal.

    The hardware I have connected on the expansion header basically has two CAN transceivers, IO expander and is what provides me the provision for connecting the battery and NTC to those battery access points. The only way I see some problem can occur with power is through the PWR_BUT and SYS_RESET.

    Any idea on what might send a shutdown request?

    I am connected to hardware through a PC remotely so I cannot share with you a direct capture from the oscilloscope but I can observe the oscilloscope remotely. Hence I have not shared the oscilloscope capture. If you still need the oscilloscope capture I can share a cutout of the webcam view.

    Appreciate your help till now. Thanks.
  • 0 in reply to sanchayan maity
    TI__Mastermind 30310 points

    I have captured an entire power-on sequence that does not involve pressing the push-button at all (PB_IN pin on TPS65217 PMIC).

    First, the battery voltage comes up and SYS follows it to 4.1V

    Because the PB_IN push-button is not pressed, LDO1 stays off.

    Then the AC voltage ramps up to 5V, SYS follows and LDO1 turns on because AC ramping is a wake-up event.

    The the battery is removed and you can see battery detection is attempted. The battery is replaced at 4.1V and LDO1 has been powered-on the entire time.

    Then the AC power is removed. The SYS voltage drops to 4.1V, but still LDO1 does not turn off. 

    Then AC power is re-applied and SYS goes back up to 5V.

    As you can see, the dynamic power path management is completely automatic and at no time does LDO1 turn off. Therefore, the PMIC remains on the entire time.

    Channel 1 = AC

    Channel 2 = SYS

    Channel 3 = LDO1

    Channel 4 = BAT

    If your issue cannot be resolved by using this scope shot as a reference, then it might be a good idea to post a new question about the Beagle Bone Black or AM335x processor, as the PMIC is not causing the BeagleBone to shut down.

    An interrupt will be generated every time a power supply is removed. If the code on the processor tells the PMIC to shut down because an interrupt has been generated, then the PMIC will do whatever the processor tells it to do (either by I2C commands or by pulling the PMIC_POWR_EN pin low). Again, the PMIC is not in charge of this situation and would prefer to stay on whenever a valid power supply is a available.

    Thanks,

    Brian

  • 0 in reply to Brian Berner
    Expert 1810 points
    I found these discussions online on Linux kernel mailing list.
    www.spinics.net/.../msg118585.html
    www.spinics.net/.../msg118615.html

    Perhaps that solves the issue. I will take a look. If it doesn't solve the issue, I will post a one specific to BB. Thanks for your help.
  • 0 in reply to Brian Berner
    Expert 1810 points
    It works now. The problem was really with Linux driver implementation. The driver was generating a power off event on AC power status change. Had to remove that piece of code from the IRQ handler. Thanks for all your help.