TPS65220: TPS65220 PMIC not coming up on some boards

Hi Benjamin,

It looks like you are seeing the default 2 retries after the 1st power-up fails - this may be caused by residual voltage on one of the inputs that has not fully discharged. Here is another thread that goes into more detail: 

https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1229202/tps65219-residual-voltage-checks-during-start-up

There are some registers you can modify in the NVM to alter this behavior to confirm if this is the issue. You can also try to capture the input voltage on the scope to verify.

• Mask the re-try counter. Changing address 0x24, bit7 to 0x1.  This will allow the device to continue retries.
• Enable the default discharge check: changing address 0x1E, bit7 to 0x0 (This will ensure none of the PMIC rails turn-ON until they are all discharged below the SCG/RV threshold).

Best regards,

Matt

Hi Sorry if I was not clear.  This is happening on initial power on and we can not boot as none of the rails come up and there is no other external voltage other than VCC_MAIN.

Hi Benjamin,

The failed power up and retries occurs due to a fault detected during power-up. Can you try masking different faults to narrow down which fault is causing the issue (registers 24h and 25h)?

Regards,

Matt

Matt, how do we read registers on the PMIC if the pmic never powers up?

The output is not successfully powering up (due to a fault condition detected) but the PMIC should still have power, correct?

Our device AM6412 has no power

Understood. So if you don't have a way to write to I2C (this could be done with a USB2ANY module and the device GUI), it may be best to capture the input voltage and all outputs to see which fault condition could be triggering.

We'll do this tomorrow AM,  thank you

Hi Matt, we isolated the PMIC I2C bus and connected it to an external micro.  The PMIC does not appear to be sending an ack back, so we can't read from it.  Please advise.

Thanks

Hi Benjamin, It looks like the fault that is being detected is triggering a shutdown. Are you able to capture the input voltage and all outputs during power-up?

Matt

Yes, following the power sequencing, I see all the rails come up until Buck3

Green being Buck3, 1.2V

Hi Benjamin,

There must be a fault since the rails you show are also not powering on successfully. What are the blue and pink waveforms? Buck3 will not attempt to power up until the previous rails power up successfully. So it would be good to capture Buck2, LDO1,3,4 and GPIO1 to see what the issue may be.

Matt

All the other rails came up successfully.  I will get another capture today

LDO2 did not come up, but you can see a little bump on the scope.  Buck 1&3 also did not come up

Thanks Benjamin. Let me check with a couple of other experts for this device and see what suggestions they have.

Hi Benjamin,

Do you have the full OPN of the part you're using in this application?

I wasn't able to find it in this thread and it's not included in the schematic. 

Thanks,

Gerard

TPS6522053RHBR  is there another part number?

Hi Benajmin,

Ok, just needed the confirmation. That device has LDO1 enabled by default but the schematic shows Cout for LDO1 (C53) is not populated. Could you please try populating it and see if the power up sequence is successful?

FYI you can refer here for all the default settings of the TPS6522053RHBR: https://www.ti.com/lit/pdf/slvucj3

Thanks,

Gerard

LDO1 looks normal without C53.  Added a 1uF (what was available) and looked the same.  Still no boot.

Hi Gerard, as I previously stated, we tried this and were unable to receive an ack from the PMIC I2C device.

Hi Benjamin,

I didn't see what you tried the first time - did you enable the oscillator (step 2) before trying any other transactions?

Thanks,

Gerard

I was unable to read from the device over I2C, so I don't see how I could write to the device. 

Would you expect the PMIC to reset with PB input pulled low in this state?  We do not see the PMIC retry to come up after asserting PB low.

Here is what we see when we try to read the i2c bus

Hi Benjamin,

To minimize power consumption in this state, the device doesn't have the full I2C functions powered. It's only listening for a write of 0x09 to register 0x34, any other command will not get a response. After the host sends the correct write transaction, the device initializes all the necessary blocks and be fully communicative. 

Thanks,

Gerard

got it!


=> i2c mw 30 34 09 1
0000: 80    
0002: 7f    
0003: 0b    
0004: a6    
0005: 98    
0006: 05    
0007: 76    
0008: 94    
0008: 94    
0009: a4    
000a: 86    
000b: 21    
000c: 21    
000d: 50    
000e: 21    
000f: 30    
0010: 21    
0011: 41    
0012: 80    
0013: 60    
0014: 02    
0015: 60    
0016: a9    
0017: 5d    
0018: c0    
0019: 00    
001a: f0    
001b: 00    
001c: 00    
001d: 00    
001e: 02    
001f: 41    
0020: c6    
0021: 7f    
0022: 02    
0023: 00    
0024: 00    
0025: e0    
0026: 30    
0027: 00    
0268: 44    
0028: 02    
0029: 00    
002a: 7f    
002b: 20
002c: 00    
002d: 04    
002e: 00    
002f: 00    
0030: 00    
0031: 00    
0032: 00    
0033: 04    
0034: 10    
0035: 0e    
0036: 00    
0037: 00    
0041: 40   

0001: 53

Hi Benjamin,

Register 0x2D is showing that an under-voltage fault on LDO1 is the cause for the outputs shutting off. Are you sure that the capacitor was added successfully on LDO1?

Regards,

Matt

We put a 2.2uF on C53 on a second board and it still does not boot.

Yes, I think you found the issue. You could try to increase DVCC_1V8 to 3.3V to confirm since this should prevent the UV fault on LDO1.