• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 4 answers
  • Subscribers 31 subscribers
  • Views 391 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DRV8874: Wake up time

Mark Philip Felipe
Genius 10820 points
Part Number: DRV8874

Hi Team, we would like to confirm if we have other criteria aside from the wake-up time of 1ms. Do we have a wake-up time details between the waking up of to drive through fault check?

Hoping for your clarification.

Thank you very much.

-Mark

  • 0
    TI__Mastermind 37683 points

    Hi Mark,

    Thank you for posting to the Forum,

    Let me do some research on this and I will get back to you with a reply by tomorrow.

  • 0 in reply to Pablo Armet
    TI__Mastermind 37683 points

    Hi Mark,

    I just want to make sure I completely understand your question. Can you clarify what you mean by "Do we have a wake-up time details between the waking up of to drive through fault check?"

  • 0 in reply to Pablo Armet
    Prodigy 50 points

    Hi Pablo,

    Our company is the source of the inquiry. Let me pose the question more to the point:

    Could you tell us the max. delay in between wakeup and fault indication on the pin? This delay's got to guarantee any fault will have been indicated on the pin by then.

    I know there's a 1 ms wakeup time but that is regarding current output, i guess. It'd be advantageous if there'd be a shorter delay as the one I'm inquiring for.

    Thanks in advance for your consideration.

    Kind regards,

    Fisnik Kura

    R & D

    Solve GmbH

  • 0 in reply to Fisnik Kura
    TI__Mastermind 37683 points

    Hi Fisnik,

    Thank you for the clarification.

    The actual  time for a fault to be triggered can be different depending on the type of fault and other variables in the system. For example overcurrent protection (OCP) has a typical degltich time of 3µs meaning that the current needs to be above the OCP threshold (6A) longer than 3µs before the FAULT is triggered. However, OCP FAULT trigger time can be depended on load inductance and OCP trip point per FET. Likewise, the VM undervoltage lockout fault (UVLO) requires a deglitch time of 10µs for the FAULT to be triggered. UVLO FAULT trigger time also depends on UVLO trip point, VM falling rate, bulk capacitors, and power supply current. For other types of FAULTs like over temperature shutdown (OTS), it can be very difficult to determine the FAULT trigger time since it depends heavily on load current, ambient temperature, and thermal performance of the board. The trigger time can differ depending on the board and environment.

    I hope that answers your question.

  • 0 in reply to Pablo Armet
    Prodigy 50 points

    Thank you for your explanation.

    I had the suspicion the various conditions wouldn't let you make a statement on the inquired delay time. Essentially what can be derived from your statement is that the delay is endless after wakeup, do I understand correctly?

    Or is there a possibility to define a least max. (lowest upper bound) delay time? E. g. for ordinary faults and fault conditions.

    Kind regards

    Fisnik

  • 0 in reply to Fisnik Kura
    TI__Mastermind 37683 points

    Fisnik,

    [Q] Essentially what can be derived from your statement is that the delay is endless after wakeup, do I understand correctly?

    [A] Let me clarify my statement. The time it takes a FAULT to be triggered and be observed in the nFAULT pin is dependent on the fault type and other factors listed in my previous reply. In some cases, the FAULT can be triggered faster than in other cases. 

    [Q] is there a possibility to define a least max. (lowest upper bound) delay time?


    [A] A minimum delay time is dependent on the type of fault. Is there a fault which you are interested in knowing the min delay time for? 

  • 0 in reply to Pablo Armet
    Prodigy 50 points

    My intentions maybe weren't so clear. I want to enclose all faults in the consideration. I want to know how long for i have to let the driver be waking up/ awoken to know if any fault has occurred. Such that I can immediately put the driver to sleep again.

    So if there'd be only two faults, A and B, and fault A (e.g. supply undervoltage) takes 10 us whereas fault B takes 3 us, then the desired answer would be 10 us. But here there are more faults.

    Thanks for your patience and cooperation.

    Regards

    Fisnik

    R&D, Solve GmbH

  • 0 in reply to Fisnik Kura
    TI__Mastermind 37683 points

    Hi Fisnik,

    [Q]  I want to know how long for i have to let the driver be waking up/ awoken to know if any fault has occurred


    [A] A VM UVLO and charge pump undervoltage fault (CPUV) can be triggered as the device is turning on so twake (1ms) would be the answer to your question if a UVLO or CPUV fault occurs during wakeup. As for overcurrent and over temperature shutdown fault, the timing depends on whether the outputs are enable when waking up the device. If the outputs are enabled, then the answer is again 1ms (twake) assuming the fault conditions are present right when the device is waking up. However, if the outputs are enabled AFTER the device is awake, then the actual time is basically unknown as the fault can occur at any time.

    I hope that answers your question.

  • 0 in reply to Pablo Armet
    Prodigy 50 points

    Excuse the late answer as I was in holidays.

    Pablo Armet said:

    As for overcurrent and over temperature shutdown fault, the timing depends on whether the outputs are enable when waking up the device.

    What we intend to do is minimally short, periodical fault checks whilst not applying any output.

    I get it that the typical deglitch time of UVLO and OCP are 10 and 3 us respectively.

    What does this quote of yours regarding "overcurrent and over temperature shutdown" mean to say with "the fault can occur at any time"? I wanted to know if there'd be a fault, how long it'd take to get detected.

    Pablo Armet said:

    However, if the outputs are enabled AFTER the device is awake, then the actual time is basically unknown as the fault can occur at any time.

    Mind you I don't know if all of the 5 faults (TRIP, UVLO, CPUV, OCP, TSD) are even able to occur and be detected in the described scenario (no output applied). Maybe you can make a statement about that?

    Kind regards

    Fisnik

  • 0 in reply to Fisnik Kura
    TI__Mastermind 37683 points

    Hi Fisnik,

    Let me take back my earlier comment :"As for overcurrent and over temperature shutdown fault, the timing depends on whether the outputs are enable when waking up the device. If the outputs are enabled, then the answer is again 1ms (twake) assuming the fault conditions are present right when the device is waking up. However, if the outputs are enabled AFTER the device is awake, then the actual time is basically unknown as the fault can occur at any time.". What I mean to say is that if the fault condition is present prior to powering up the device (for example, the IC temperature is above the trip threshold right), then the nFAULT signal can start being monitored as soon as the device is awake (1ms) (the actual time for the fault to be registered on the nFAULT pin will differ depending on different factors so the best option is to begin monitoring nFAULT as soon as device is awake). However, if the fault condition occurs after the device is powered up, then the time from when the device is awake to when the event is triggered is impossible to be known as the fault can occur at any time (In this case, monitoring of nFAULT as soon as the device is awake is the best option to ensure that you can detect when the fault is triggered).

    If by "not applying any output" you mean not driving the outputs (IN1=IN2=0), Then UVLO, CPUV, and TSD will be able to be occur but TRIP and OCP fault will not since it requires the H-bridge to be enabled. 

  • 0 in reply to Pablo Armet
    Prodigy 50 points

    Ah, thank you for the clarification.

    As for the following:

    Pablo Armet said:
    the actual time for the fault to be registered on the nFAULT pin will differ depending on different factors

    I get the importance of this and am taking it into consideration. Of course one variant is having only this kind of 1 ms long ("more reliable") fault checks. There's also another variant we are investigating: Having more seldom of these 1 ms long fault checks and also X us long fault checks.

    For more often and quick fault checks we'd be considering to check on typical fault deglitch/ manifestation time with assumption of default/ average factors. Could you supply such typical/ average times (in microseconds range) for CPUV and TSD faults?

    Kind regards

    Fisnik

  • 0 in reply to Fisnik Kura
    TI__Mastermind 37683 points

    Hi Fisnik,

    [Q] - Could you supply such typical/ average times (in microseconds range) for CPUV and TSD faults?


    [A] - Unfortunately, I don't have the deglitch times for CPUV and TSD faults. However, if what you only want is to know for how many X us to periodically check for fault, I would recommend 3us (the OCP deglitch time). Under normal operating conditions, OCP will have the fastest  fault triggering times compared to all the other faults. But also keep in mind that the driver protects itself after a fault is triggered. So you don't have to develop an algorithm to protect the driver by monitoring nFAULT unless you are looking to create a more solid fail-proof protection scheme.