TPS65217: TPS65217B PWR_EN pin maximum deglitch time

Catalin,

If the datasheet does not give a minimum or maximum value, then I am not able to speculate what this value could be. Most timing parameters are not testing in production because the entire test could be shorter than a 5 or 8-second timer (the TPS65217 has both!)

When PWR_EN is transitioning from Low to High, it needs to be high and stable withing 5 seconds from the beginning of the power-up sequence (as shown in Figure 3 on page 19 of the datasheet). Compared to 5 seconds, 50ms is a negligible amount of time and the maximum will not be 2 orders of magnitude higher than the typical (5s/50ms = 100).

On a falling edge of PWR_EN (High to Low), the power-down sequence is executed immediately after the de-glitch time expires, but generally speaking the falling edge is not as critical for de-glitching. A High-to-Low transition is usually fast and deliberate.

Are you having any specific issues with the TPS65217 device that are related to the de-glitch time on the PWR_EN pin?

Catalin,

I apologize for the delay, but I am unable reproduce your issue on my lab bench setup using the TPS65217CEVM.

The scope is setup just like your attachment and both rails (VDCDC3 and LDO3) go low approximately 50ms after PWR_EN goes low, and VDCDC3 never spikes up above its setpoint.

Is it possible there is something unique about the way you are testing the EVM? 

Are you aware that PWR_EN can toggle an infinite # of times in 5 seconds after going high the 1st time and all toggles will be ignored until the 5 second timer expires?After the 5s ends, the next low edge causes the power-down sequence. This timer runs regardless of whether or not the input voltage has recently powered-on. 

The same thing goes for when PWR_EN toggles low: PWR_EN can toggle many time until the 1s delay expires before the next low-to-high edge is recognized and the power-on sequence occurs.

Trying to run tests quickly on the EVM can lead to assumptions that the device is not working, but that is only because there are a lot of delays in the part. Edges are captured while the delay is running, but nothing will occur until the delay expires. Trust me, I have been there before and made many of these assumptions myself.

I hope this resolves the question related to PWR_EN.

However, I still firmly believe the spike on DCDC3 is related to the processor and improper sequencing. It is possible the PWR_EN issues were causing this improper sequencing, but I cannot say for sure.

Any rail rising unexpectedly on the PMIC is usually traced back to a leakage path through the processor and is not the PMIC spontaneously changing voltages.