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

Original question:

TPS65218: DCDC5/6 no output when power supply from Coin Cell input on CC(Pin25)

TPS65218D0: Trying to get FSEAL to break

Timothy Barr
Genius 3370 points
Part Number: TPS65218D0
Other Parts Discussed in Thread: AM4372, TPS3825, TPS65218, , BOOSTXL-TPS65218, IPG-UI

I have a design using the TPS65218 to power a AM4372 processor. I want to be able to go into a low power mode and wake up from RTC or external signal and I want my unit to always power up without having to use the push button, but my design may not always have coin cell battery attached. So I connected the CC pin to my input voltage with a resistor divider to drop the voltage to an acceptable level. I also connected the AC_DET pin to the RESET* pin of a TPS3825 power supervisor so that the AC_DET pin is pulled down on low power and then pulled up after. I tested this circuit on the first rev of my prototype and it worked as I expected. But when I had multiple units built with the changes I can not get consistent FSEAL breaking. Some boards will break FSEAL and some boards won't.. 

  • 0
    Genius 3370 points

    Additional info:

    I removed the supervisor from AC_DET and grounded the AC_DET pin. I booted the processor into u-boot and then used i2c commands to look at the TPS65218. Still do not see the FSEAL bit go high on some boards. I did review the u-boot code and it does attempt to break FSEAL. I also did a CC AQ and the TPS65218 reports Ideal coin cell level.

  • 0 in reply to Timothy Barr
    TI__Mastermind 30310 points

    I think your debug effort is off to a good start. 

    First, I just want to clarify that you are using the TPS65218D0 and that you are not using the TPS65218 (-B1 version, which is NRND). The Part # for your question shows "TPS65218D0" but the title and body of the question say "TPS65218".

    Secondly, you need to ensure that the system turns on and stays on.

    "I also connected the AC_DET pin to the RESET* pin of a TPS3825 power supervisor so that the AC_DET pin is pulled down on low power and then pulled up after." This does not sound like the correct implementation of AC_DET. You want AC_DET to be pulled low when the power supply to the supervisor is in the acceptable range. nRESET has the opposite polarity of what is required for AC_DET, which is why AC_DET is shown connected to a FET in Figure 5-27 (A) of the TPS65218D0 datasheet: The gate is driven high when line power is good, which drives AC_DET low to wake-up the system without a push-button.

    AC_DET = GND will ensure the PMIC turns on as soon as powered is applied, but it will not keep the system on for more than 20s.

    PWR_EN = High will ensure the system stays on for an indefinite amount of time. Please ensure that PWR_EN is not Low during your test or you may not have time to write the sequence to break the FSEAL (flip the bit from 0b to 1b).

    During the entire power-on and I2C write process, it is necessary to ensure that the CC voltage is within the acceptable range (2.2-3.3V, 3.0V nominal). But this won't do you any good if your main power supply is not stable.

    It is also necessary to ensure that VIN_BIAS and VSYS_BU are within the acceptable voltage range (2.7-5.5V) during the entire procedure.

    What are the resistor values in your divider and their tolerances? What is the nominal input voltage to VIN_BIAS?

    If you look at the I2C lines with a sniffer, can you see a consecutive sequence of [0xB1, 0xFE, 0xA3] being written to the PASSWORD Register (Reg. address 0x10)?

    How are you verifying that the FSEAL bit is broken? Are you reading back the STATUS register (0x05) with no changes to the power supply, or are you cycling power to the system? If you cycle power to the system without a physical coin-cell battery, then obviously the system enters the "NO POWER" state of the state machine (shown in Figure 5-34. Modes of Operation Diagram), so the FSEAL bit will return to its unbroken state (0b).

    With all power remaining high and stable, toggling PWR_EN to low with FSEAL=1b will result in DCDC5/6 staying on when the PMIC transitions to the OFF state.

    For my testing, I did this on the BOOSTXL-TPS65218 with an IC that has been used to test re-programming the EEPROM.

    Using the IPG-UI, you can see that when I use the Macro to toggle the FSEAL bit, the MSP430 writes [0xB1, 0xFE, 0xA3] to Reg. 0x10 consecutively.

    Then, for the sake of argument, I sent 1b to bit 0 (CC_AQ) of Reg. 0x06 (CONTROL) to see the CC voltage is in the "IDEAL" range.

    You can see that FSEAL=1b and CC_STAT=11b (ignore the fact that EE bit = 1b, so the value you should see in STATUS is 0xAB).

    Finally, I toggle PWR_EN from Hi to Lo and verify that DCDC6=1.8V & DCDC5=1.0V while every other rail (DCDC1-4 & LDO) is turned off by the sequencer.

  • 0 in reply to Brian Berner
    TI__Mastermind 30310 points

    It should be noted that in my testing, VIN_DCDCx = VIN_LDO = VSYS_BU = VIN_BIAS = 5V (from USB) and CC=3.3V, and that neither of these voltages change at all throughout the entire procedure.

  • 0 in reply to Brian Berner
    Genius 3370 points

    On further investigation, I found there were multiple issues that were masking the main issue. Reviewing all the u-boot I2C communication with the TPS65218D0, I found that no FSEAL break sequence is being sent. There is a an fseal_break function in the TPS65218 driver but it is never called in u-boot.

    Masking item 1 is that for some reason some of the TPS65218D0 parts parts power up with FSEAL already set to 1. My design is not using a coin cell on the CC pin. Instead, I have a resistor divider connected to the same source voltage as my input voltage (5VDC) . SO that was confusing to begin with.

    Masking item 2 is that when I tried to break FSEAL in u-boot using the I2C commands, it did not seem to work. Upon further investigation I found that for some reason the I2C write command sends the same data twice. So i was never sending a proper FSEAL sequence. But using the pmic write command I was able to send a proper FSEAL sequence. Should I post this issue on the AM4372 forum as well?

  • 0 in reply to Timothy Barr
    TI__Mastermind 30310 points

    Yes, definitely. If you know the root cause is related to software/firmware, feel free to start a new thread about the AM437x code/drivers.

    Be sure to let them know how you came to this conclusion so the new thread doesn't get redirected back to here.

  • 0 in reply to Brian Berner
    Genius 3370 points

    Any thought on why some of my boards have FSEAL set to "1" all the time? According to the datasheet,"Coin-cell battery and main supply must be disconnected from the IC to reset the FSEAL bit again." That happens whenever i power down my board, but some TPS65218D0 parts don't clear this bit.

  • 0 in reply to Timothy Barr
    TI__Mastermind 30310 points

    Timothy,

    Are you sure you are using the TPS65218D0?

    It sounds like you are actually using TPS65218 -B1 silicon. What is the top-side marking on your IC?

    The reason this sounds like you are using the older -B1 silicon is because there was a bug identified related to FSEAL bit unexpectedly flipping from 0b to 1b on its own without writing the proper I2C sequence. This sounds very similar to what you described.

    The root cause was identified as a slow ramp of the CC pin voltage, which causes a flip-flop to become unstable. The maximum recommended slew rate for -B1 silicon would be 7.5mV/us, or 300us for the CC pin to ramp from GND to 2.2V

    -D0 silicon fixed this issue, and the TPS65218 (-B1 silicon) is marked as NRND.