TPL5111 unexpected POR behavior

I've notified an engineer to respond. Thanks.

Hi Douglas

looking at your trace it doesn't seem a "false" POR detection.
In your traces seems that the DRVn change before the VDD change.
I don't know your schematic, but Is it possible that the DRVn shut down a portion of the system and this cause the change in VDD>

Anyway, TPL5111 sequence on POR is that the VDD change and after 200ms the DRVn is asserted HIGH (not low as in your traces) until a DONE signal is received OR it reach the end of the programmed time interval.
Time interval is programmed via the external resistance.

Could you please verify the sequence DRVn and VDD jump again?

Regards
Massimo

The DRVn pin is pulsing high for about 7.5 seconds each time.

It's the time between pulses that is short.

See attached PDF for a detailed explanation.

Let me know if I misunderstood something

TPL5111 Unexpected POR Issue.pdf

Hi Douglas

looking at the high level schematic in the pdf file, the TPL5111 behaviors is correct.

In the schematic the DONE input is connected to GND. It means that there isn't any DONE event (DONE signal high) that lower the DRV signal.

In this case 50ms before the end of programmed Tip the DRV is forced LOW and the cycle restart.

The situation you PRINT_02.tif is ok and described in figure 10 page 10 of TPL5111 datasheet.

In your pdf, is not describe how often and for how long you want the 4.2V ENn pin activate.

A way to implement a square wave with programmable duty cycle is the follow:

Changing the RC value is possible to change the duty cycle of DRV generating a signal that periodically enable the 4.2V LDO.

I hope it gives you some hints on how to use the TPL5111 in your application.

Best Regards

Massimo

I'm not trying to have DRV operate in a duty cycle/repetitive mode, and I'm not trying to shorten the pulse with DONE.

Let me restate my observation:

If VDD jumps from about 3.2V to about 4.2V It looks like the TPL5111 treats this like a power-on event and after about 80ms asserts the DRV signal.

Why does TPL5111 treat this as a POR?

If VDD transitioned from 0V to a valid voltage (1.8V to 5.5V) I would expect a POR.

If VDD transitions from something less than 1.8V to something more than 1.8V I could understand a POR.

If VDD transitions from one valid voltage to another valid voltage I don't expect a POR.

But that's what it appears to be doing.  If VDD transitions from 3.2 to 4.2V then TPL5111 treats it like a POR.

It seems like there should be an errata or a note in the datasheet about this.

FYI: One example of a well-characterized POR circuit can be found in pages 33-34 of this TI processor data sheet.
www.ti.com/.../slas368g.pdf
I'm looking for this kind of information on the TPL5111

Dear Douglas

 

Thanks for link.

We tried to replicate your setup to verify if a change in the voltage supply triggers a POR event.

We replicate your set application set up in simulation and in the lab with the available TPL5110EVM. TPL5110 and TPL5111 have the same behaviors with inverted DRV polarity.

The simulation didn’t show any POR event.

In the lab we use a TPL1110EVM powered with a power supply that periodically change its value from 3.2V and 4.2V.

To well identify the possible POR event the change in the voltage supply are asynchronously generated respect to the timer period. POR event is not triggered

Fig 1

Based on our test I will exclude that the unwanted POR event when the power supply change from 3.2V to 4.2V

I would like to come back to the “Missing done” behaviors of the TPL5110/TPL5111

 

Fig 2

Figure 2 describe the TPL5111 missing done behaviors.

 As you can see the behaviors is very similar with what you described and the fact that the DRV drives the 4.2V LDO making the events happen at the same time. In the below figure I also added the voltage supply value that bounces between 3.2V and 4.2V

The above description should describe the behaviors you are seen on your application

Best Regards

Massimo

Did you have EN/ONE_SHOT set low on the TPL5110EVM you used for Figure 1?  

Is trace 1 the VDD pin and trace 2 the DRV pin in Figure 1?

Are you saying that if DONE is NEVER pulsed, then DRV will continue to pulse hi/low forever even with EN/ONE_SHOT set low?  (That's what your Figure 2 is showing?)

If that is the case, then the datasheet needs to be corrected.

Right now it states:

When EN/ONE_SHOT = HIGH, the TPL5110 works
as a TIMER. When EN/ONE_SHOT = LOW, the
TPL5110 turns on the MOSFET one time for the
programmed time interval. The next power on of the
MOSFET is enabled by the manual power ON.

and

During One shot mode (EN/ONE_SHOT = LOW), the TPL5111 generates just one pulse at the DRVn pin which
lasts according to the programmed time interval. In one-shot mode, other DRVn pulses can be triggered using
the DELAY/M_DRV pin. If a valid manual power ON occurs when EN/ONE_SHOT is LOW, the TPL5111
generates just one pulse at the DRVn pin. The duration of the pulse is set by the programmed time interval. Also
in this case, if a DONE signal is received within the programmed time interval (minus 50 ms), the DRVn output is
asserted LOW.

That means that if EN/ONE_SHOT is low you get one DRV pulse on power up and never again until M_DRV is pulsed or VDD power cycles.

I also don't believe the "missing done" explanation because if it were true my board could never get out of a repetitive power cycle.  The DONE pin is shorted to ground on my board.  There is no way for me to pulse it, but if I prevent the 3.2V-4.2V oscillation my board starts up fine and continues working without power cycling.

Dear Douglas

The graph reported in the previous post was made on an TPL5110EVM in timer mode.

We have just replicate the set up you indicated an with a VDD variation a Power On Reset event is triggered.

Only on the rising edge of the VDD triggers the event

We are doing further investigation on this behaviour, we will add the results in the next datasheet release.

Please find below an oscilloscope capture that indicate the POR.

- Yellow = VDD

- Blue = DRV

- Purple = DELAY/M_REST

Best Regards

Massimo

I'm glad that you were able to reproduce it and that you're going to update the datasheet.

Do you have an idea of when the updated datasheet will be available?