AM3351: Setting TPS65218D0PHP FSEAL bit using TI driver with AM3351

Specifically, we're using the TPS65218 driver.  We found the function "tps65218_lock_fseal()" in pmic_tps65218.c, but it's not clear to us how we're intended to invoke it; it doesn't appear to be called from elsewhere in the driver, and it doesn't seem to be exposed to an ioctl or similar.  Is there any guidance as to how this is supposed to be used?  In case it's relevant, our product mainly runs as a user-space application under Linux, but we're comfortable with rebuilding the kernel if necessary.

Hi Owen,

I am routing your query to the PMIC team for comments.

Hi Owen,

Since this function is part of the U-Boot driver, I've found an example of where it's used. Hope this is applicable to what you were looking for.

https://concept.u-boot.org/u-boot/u-boot/-/blob/acce3463797def22b71e3c6d8ff9a4844941cdf7/board/compulab/cm_t43/cm_t43.c

Thanks! I'd missed that the function was actually in U-boot rather than the kernel, but porting it to the kernel driver was straightforward (I put it in the tps65218.c file, at the end of the probe function).

However, while it runs, it doesn't seem to actually set the FSEAL bit.  In the driver I put a readback of the status register after attempting to set FSEAL, and it's still reported as 0x08.  I added some code to monitor the register writes to the PMIC, and it's reporting what I'm pretty sure is the correct sequence (register 0x10, with the values 0xb1, 0xfe, 0xa3, 0xb1, 0xfe, 0xa3, 0xb1, 0xfe, 0xa3).  Are there any suggestions as to what might be going wrong there?

Hi,

Consulting with the Apps Engineer for that device on the sequence specifics. Will get back to you after we look into this!

Hi Owen, 

Could you clarify, that there aren't any readbacks performed between the writes, and the readback is performed strictly after the writing sequence is done?
Any interruption to the consecutive writes could disturb the sequence. 

If this isn't the issue, then could I suggest setting this integer to 1 or 2 to see if this changes the FSEAL bit?

The three writes should be locking the bit as '1', but I would want to test if the bit is being successfully toggled at all in the first two writes.

Could you also confirm some questions about your design:

• Is coin cell and/or AC_DET being used?
• Is power-on sequence initiated with PWR_EN, AC_DET, PB, or IN_BIAS supply ?

Best Regards,
Sarah

Hi Sarah,

That's correct on the readbacks: we issue the writes consecutively, with no intervening reads, and we read the status right afterwards.

Changing the loop counter to 1 or 2 made no difference; we get a status of 0x08 for 1, 2, and 3 loop iterations.

For the design questions, I'll have to defer to my colleague Tom; he's much more familiar with the hardware design than me. 

Hi Sarah,

regarding the hardware:

• AC Detect is unused, pulled high. 
• IN_BIAS is unused, pulled high 
• Push button PB is unused, tied high
• The coin cell CC input is connected to a 3V coin cell, through the recommended diode/resistor network
• We can remove the coin cell battery to test this FSEAL process with/without the battery backup
• Power-on sequence is initiated using PWR_EN input, which is tied to the "power good" output of the system main power supply.

thanks for your help.  Let us know if you have other questions.

Best regards,

Tom

Hi Owen, Tom, 

Thanks for the insight.

Could you clarify what you mean by "IN_BIAS is unused, pulled high" ?
IN_BIAS should just be the supply voltage to the PMIC, 2.7 V - 5.5 V.
Please ensure that the proper input voltage is being supplied. 

Please keep the coin cell inserted when setting the FSEAL bit.
We have noticed that the CC pin needs to have a valid voltage of 2.2 V - 3.3 V in order for this bit to be set properly. 

Could you also try hooking up some sort of I2C sniffer to the bus to ensure that these write commands are being received on the hardware side?

Best Regards, 

Hi Sarah,

• We are sure the proper input voltage is supplied.  Our input voltage is 4.1 volts, and we've confirmed it is present. Besides, we could not run these experiments without it on.
• IN_BIAS is connected to the input supply voltage.  This is the meaning of "IN_BIAS is unused, pulled high".
• CC is 3.2 volts on the PCBA under test.

We will instrument the I2C sniffer and post the measurements here.  This will take a couple days to work thru.  

Best regards,

Tom