TPL5010: Reset why?

Adding the schematic

Hi Nathalie,

Were MAIN_BOOST_EN and SMPS_EN triggered by RSTn or the other way around?

Is WAKE connected to somewhere else?

Trigger set on Watchdog_Reset#

Wake is not plugged in the design, just put a probe on the signal to see it.

Hi Nathalie,

RTSn will assert when the device did not get the DONE signal before the next WAKE is asserted. 

Do you have a 100ns DONE pulse width?

Since you are not using WAKE, your DONE signal is not synchronous with the WAKE. There is a possibility that you are giving the device the DONE signal not at the right time, the device did not receive the DONE signal within the time interval and therefore assert RTSn. 

DONE pulse width is 10.4usec.

Do we have too many DONE pulse that could create a reset?

Hi Nathalie,

Not sure but the first DONE signal within the time interval has already reset the internal counter, the following DONE are ignored and should not hurt the device.

So every 4sec, DONE Pulse is not enough to create any reset?

Also found out 5 years ago this chat:  I recently came across a thread that mentioned there is a phenomenon where if you send too many DONE pulses that it can append the time duration to the next time duration.

e2e.ti.com/.../tpl5010-inconsistent-rstn-time-periods---using-as-watchdog---recommendations

Hi Nathalie,

If that is true, can you use the WAKE signal to trigger the DONE signal?

Not sure to understand the question? 

The PCB + product design cannot be change...

Is this a known issue for TPL5010, too many DONE pulses...  

Hi Nathalie,

We don't know if this is a known issue, this product was not design and characterized in our team. 

All I can do is to verify this in the lab, see if I can replicate the problem. I am not in the office these days, I will ask somebody in the team to help.

Hi Nathalie,

I went into lab to try to replicate this. I used the TPL5010EVM. I have attached the oscilloscope capture below.

As you can tell, I am manually issuing several DONE pulses (purple waveform) to the device during each interval, but the device never issues a RESET signal (i.e. the RSTn pin never pulls low, the blue waveform on the scope), and the WAKE signal (green waveform) pulls high at the end of each interval. 

Noel and I will set up a more formal test on Monday to see if we can find the source of the issue. 

Thanks,

Michael

Hello Michael, it's a tricky bug because I could let it run for days without any reset and then after 14 days bang it happened a reset.  

Hi Nathalie,

That issue sounds somewhat familiar. I will check our e2e records to see what I can find, but I will be setting up a more formal test tomorrow.

Thanks,

Michael

Hi again Nathalie,

From what you have described and what I have read in our older E2E forums, you are experiencing a spontaneous Reset event, which can be caused by one of three things:

• Missed DONE signal
• DELAY/M_RST pulse high > 1.5V lasting longer than 20ms
• POR of the timer

I cannot imagine the DONE signal was missed, given the waveforms you shared earlier (although we will put a pin in this). Furthermore, your DELAY/M_RST pin was never asserted high. Lastly, the VDD pin never changed its state - but, there may be other circuits or noise on the 3.3V bus that trips the internal UVLO and POR sequence. Can you probe the VDD line with an oscilloscope to see if there is any noise? Furthermore, where is C14 physically located? Is it right next to the VDD/GND pins?

Based on the E2E forum you shared, it does seem possible that a high rate of pulse arrival could result in Reset events occurring unexpectedly. It is difficult to ask you to retake data given that the issue is so sporadic, but does the issue get any better when you decrease the frequency with which you issue DONE pulses, as you asked below?

Nathalie Gauthier said:

So every 4sec, DONE Pulse is not enough to create any reset?

In the meantime, I will be setting up a function generator to input a square wave to the device with a longer period (> 1 minute).

Thanks,

Michael

I've reviewed and have a THEORY.  Discussed with Noel.  See description below.

Natalie's image above...

If you zoom in on the first WAKE pulse on the far left, this appears to have a DONE pulse overlapping it.  Hard to tell because of the resolution, but it's good to have this zoomed out to see the sequence.   That DONE pulse appears to violate the device spec for tDdone (min 100ns).  This is tDdone spec, not tDone spec (one extra D in this one).

This spec suggests that if the pulse edges are within 100ns of each other, there could be a problem / race condition.  Latching this mis-timed DONE pulse could cause the rest of the DONE pulses to be ignored for that WAKE cycle, resulting in the RSTn pulse later.  In other words, if a DONE pulse timing failure was logged by the part, it possibly is no longer looking at the other DONE pulses, instead just waiting for a timer to expire to send the RSTn signal.

The 2nd WAKE pulse appears to overlap black space in the DONE waveform, so no DONE pulse overlapping it or within 100ns.  Therefore, no RSTn pulse in that WAKE cycle.

I suspect you would not see this issue in other e2e unless there is another customer not using the WAKE signal, pulse DONE in an open loop fashion in the same way.

Of side note, there is a suggestion above that DONE is sent every 4 seconds.  This is not true.  That may be an average, but the timing between DONE pulses appears to be a bit random.  Image below taken from above.

Suggested DOE

Using an EVM, set the timer of the TPL5010 to 5 seconds instead of 32 min.  Use a data generator (DG2020 or similar) to send 500 ns wide DONE pulses with 1015 ns period or similar to shmoo the DONE edge relative to the 5 second timer setup on the WAKE edges.  If the theory is correct, we will see failures that generate RSTn signals quickly and be able to demonstrate a root cause from the bench.

Other Action

Reed will have digital team start looking for the RTL code location.  The problem appears to be very digital in nature.