Other Parts Discussed in Thread: TIDA-050038, TPS6521815
Hello TI Forum,
I have a circuit that utilizes the TIDA-050038 reference design. This design uses a TPS6521825 and LP873347 PMIC to provide power to an i.MX 8M mini processor. This reference design has the TPS PMIC generate the 3.3V rail, and feeds that rail to the input of LDO0 on the LP PMIC; LDO0 then generates a 1.2V rail.
Based on the preprogrammed delays in each of these PMICs, the 3.3V and 1.2V rail are supposed to come up at the same time: the TPS PMIC enables the LP PMIC, waits 12 ms, then enables the 3.3V rail, meanwhile, the LP PMIC gets enabled, waits 12 ms, then enables the 1.2V rail. So in theory, both rails should turn on at the same time; however, in practice, this is not always the case.
I have a quantity of 13 identical CCAs, and 2 of these boards have an issue where the 3.3V rail takes too long to turn on and sends the board into a fault state. The other 11 CCAs function correctly. To illustrate the issue, I am attaching a couple photos: one where the CCA turns on correctly, and one where the CCA enters a fault state. In both oscilloscope captures, I measured the time it takes from the TPS PMIC enabling the LP PMIC to the 3.3V rail turning on. On the board that is faulty, the 3.3V rail takes about 12.36 ms to start turning on the 3.3V rail. Shortly after that, you see the 1.2V rail attempt to turn on. At this point, the 3.3V rail is not high enough to allow the 1.2V rail to fully turn on. 1 ms later, the LP PMIC measures the 1.2V rail, sees that it is below the short-circuit threshold, and triggers a fault because it thinks there is a short circuit on the 1.2V rail. On the functional board, the 3.3V rail turns on approximately 11.5 ms after the LP PMIC is enabled. About 700 us later, the 1.2V rail attempts to turn on and is successful because the 3.3V rail is high enough.
So, the source of this fault appears to be the TPS PMIC taking too long to enable the 3.3V rail. Is there anything I can do to shorten this delay? The TI reference design also appears vulnerable to this fault. When it was being designed, was this issue encountered? If so, how was it handled in that case? Since the delay is burned into the TPS IC, I'm not sure what modifications I can make to fix this issue.