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.

TPS65218: How to set FSEAL bit over I2C

Part Number: TPS65218


Dear TI Team,

We tried below commands to break fseal bit on TPS65218D0. But up to now we could not set it whatever we tried.  So that can you please tell us what is needed to set Fseal bit to 1b over i2c?

BTW, we have a coin cell connected to CC pin. And it generates 3.3V. 

Commands we tried consequently:

i2cset -f 0 0x24 0x10 0x7D

i2cset -f 0 0x24 0x10 0xB1

i2cset -f 0 0x24 0x10 0xFE

i2cset -f 0 0x24 0x10 0xA3

After these commands when we check the register 0x5, we have seen that Fseal bit is not set to 1b.

i2cget -f 0 0x24 0x5

0x28

Regards,

Zafer Çalışkan

  • Zafer,

    You need to write [0xB1, 0xFE, 0xA3] to register 0x10 in order without any other I2C reads or writes in between.

    Since you are using the Linux command line, and the processor has access to the I2C when you are not writing to the PMIC, it is possible another I2C command is written in between these 3 commands:

    i2cset -f 0 0x24 0x10 0xB1
    i2cset -f 0 0x24 0x10 0xFE
    i2cset -f 0 0x24 0x10 0xA3

    Also, I'm not sure why you are writing 0x7D to register 0x10 before these 3 commands. The data 0x7D is not ever written to PASSWORD and the PASSWORD register itself is not password protected. For example, if you were going to write data to 0x11 (ENABLE1), you would write 0x6C (0x11 XOR'd with 0x7D) to register 0x10 before writing data to 0x11.

    I'm not sure if writing 0x7D to register 0x10 is messing up the FSEAL break sequence, but I think a good alternative would be to clear the buffer before starting the sequence to confirm that the readback data clears to 0x00. Also, when I use the i2cset or i2cget command, I include the '-y' option. Finally, before I write to an I2C bus I use the i2cdetect function to make sure I'm talking to the correct I2C bus (register address 0x24 shows as "XX" or "24" in the grid):

    i2cdetect -r 0
    i2cget -f -y 0 0x24 0x10
    i2cset -f -y 0 0x24 0x10 0xB1
    i2cset -f -y 0 0x24 0x10 0xFE
    i2cset -f -y 0 0x24 0x10 0xA3

    If this does not change the results, I would recommend you record the I2C transactions on bus 0 using an I2C sniffer so you can share the datalog for these transactions. Also it could be useful for me to review the schematic. Lastly, you could also use the CC_AQ field in the CONTROL register (address 0x06) and then read back the data in the STATUS register to confirm that CC_STAT = 01b, 10b, or 11b. If CC_STAT = 00b, then it indicates the PMIC doesn't measure a valid voltage on the CC pin.

  • Brian,

    Thanks for your detailed reply. After raising this case, yesterday we tried below command set and were able to set fseal bit to 1 successfully.  

    i2cset -f -y 0 0x24 0x10 0xb1 && i2cset -f -y 0 0x24 0x10 0xfe && i2cset -f -y 0 0x24 0x10 0xa3 && i2cget -f -y 0 0x24 0x5

    BTW,  is there any register to control current consumption of DCDC5 and DCDC6 LDOs in power-off mode?

    Regards,

    Zafer Çalışkan

  • Zafer,

    Thanks for confirming! Glad FSEAL=1b was set properly.

    There is no register to control DCDC5/6 current consumption because they are already optimized for efficiency to run off the Coin Cell battery. The maximum current output for DCDC5/6 is only 25mA, but they always operated in pulse-skip mode and will only switch in order to keep the voltage above the threshold (DCDC5=1.0V, DCDC6=1.8V).

    If there is no load on either DCDC5/6, you can see that they only switch about once every second. The current consumption is very low.