• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 62 subscribers
  • Views 960 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

bQ51003 Minimum pulse times for EPT End Chg or EPT Fault?

Bob Plott
Prodigy 230 points
Other Parts Discussed in Thread: BQ51003

Given the 10ms de-glitch time of the comparators I suspect the minimum pulse width for an EPT on the TS-CTRL pin to be at least 20ms. This seems to be the case for high going EPT End of Chg. But for low going EPT Fault the pulse width needs to be much longer. Any idea if this is true or why?

-Bob

  • 0
    TI__Genius 14890 points

    Bob,

    Yes, 20ms is the correct time for the high pulse.  The low pulse is much longer because it's actually a different control mechanism.  The device samples for the high going pulse every 8ms (plus the de-glitch time).  The expectation is that, to terminate, the pin would be pulled high and not necessarily pulsed.  But, if pulsed, it would need to be 20ms as you stated.

    The low case for termination is a different function.  That function is sampled every 250ms (nominally) and requires 2 consecutive pulses to occur for termination.  So, depending on when the pin is pulled low related to the sample time, the termination could happen within about 250ms or as long as 500ms.

    Regards,

    Dick

  • 0 in reply to Dick Stacey
    Prodigy 230 points

    Dick,


    Further testing of the EPT01 signal with a BQ51003EVM and both a BQ500211EVM and a commercial TX pad show that a 20ms pulse width does not always register as an EPT01 signal. In fact I have recorded pulses as long as 50ms being ignored. (70ms looks good.) My setup is a pulse gen driving the TS/CTRL through a diode, 2V amplitude, 5 second period, 20-100ms pulse width.

    I guess I don't quite understand what minimum pulse width is needed to assure EPT01 detection. We'd like to avoid needing to put in tests to see if it terminates. Any idea why this is happening?

    Best regards, Bob

  • 0 in reply to Bob Plott
    TI__Genius 14890 points

    Bob,

    The original intent for this pin was to pull high to terminate and not send a pulse.  We are beyond that now and I can give more insight as to what's going on inside the bq51003.

    There are several other process going on inside the bq51003.  To make sure the process don't interfere with one-another, when there is overlap, priority is given to specific events.  Since the expected use case was pulling the TS/CTRL pin high and not a pulse, its priority is lower.  As a result, when process overlap, the timing on the TS/CTRL pin can cause a delay in reaction.  Communication of power packets is one of the key processes that will have an impact on the timing.  Your assessment of 70ms covers almost all of the situations.  But, there is one worst case that goes beyond that.  We calculate that the worst case (when all timings are aligned) could be about 111ms.

    The safest way to ensure TS/CTRL functions as intended is to hold TS/CTRL high until the TX removes power.

    Regards,

    Dick

  • 0 in reply to Dick Stacey
    Prodigy 230 points

    Thanks Dick,

    I really appreciate the information you provided with your answer. It makes the operation much more understandable. I can now give the Firmware Eng both choice and rationale for how they would like to send the EPT signal to the pin.

    Best regards,

    Bob