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.

DRV8323: t_dead and t_drive with software deadtime

Part Number: DRV8323

Hello,

I'm using the gate driver DRV8323 with software deadtime and have a few questions regarding the timing behavior.

  1. Where does the t_drive exactly starts? At the input signal change or after the propagation delay, so when the driver starts to set the I_drive current and the gate-source voltage starts to change?


  2. The picture below shows a software deadtime of 1000 ns, a t_dead of 200 ns and a t_drive of 4000 ns.
    The two cursors are marking the time between the signal change of the highside FET (red) and the point where the gate-source voltage starts to rise.
    Where does this time results from? I would expect to see just a propagation delay here.
    Can you please describe the DRV timing behavior here?




  3. The picture below shows a software deadtime of 1400 ns, a t_dead of 200 ns and a t_drive of 1000 ns.
    The timings are chosen that the switch-on pulse (Digital 4) for the highside FET (red) occurs when the t_drive is already over.
    Which timing can we expect here (marked with the cursors)?


Thank you in advance for your answer

Tobias Widmann

  • Hi Tobias,

    Thank you for posting to the Motor Driver's forum!

    I will aim to provide a response by the end of Wednesday next week.

    Best,

    ~Alicia

  • Hi Tobias,

    Where does the t_drive exactly starts? At the input signal change or after the propagation delay, so when the driver starts to set the I_drive current and the gate-source voltage starts to change?

    tDrive starts when GHx or GLx changes state. It starts when input going low, and it starts when input going high + deadtime + tdead.

    The picture below shows a software deadtime of 1000 ns, a t_dead of 200 ns and a t_drive of 4000 ns.
    The two cursors are marking the time between the signal change of the highside FET (red) and the point where the gate-source voltage starts to rise.
    Where does this time results from? I would expect to see just a propagation delay here.
    Can you please describe the DRV timing behavior here?

    the deta time is the tdead=200ns. In this case, there is no dead-time insertion by the driver because software already added 1000ns. IOW, if you had programmed tdead=0 then the delta between cursors = 0s. 

    Btw, no reason for adding software deadtime 1000ns, as the driver chip will insert the proper deadtime. Too much deadtime will cause phase voltage distortion leading to audible noise.

    The picture below shows a software deadtime of 1400 ns, a t_dead of 200 ns and a t_drive of 1000 ns.
    The timings are chosen that the switch-on pulse (Digital 4) for the highside FET (red) occurs when the t_drive is already over.
    Which timing can we expect here (marked with the cursors)?

    Again, the delta time = 200ns tdead, starting after INHx going high + total deadtime (which is chip deadtime + tdead) 

    You should try with zero software deadtime, then adjusting tdead for a minimum separation between GHx and GLx to ensure the FETs are not shot through.

    Brian

  • Dear  Brian,

    thank you for your answer. Can we please fix first of all the wording for all the times? I regular use:

    • software deadtime for the time the input signals INxx are delayed
    • t_dead for the selectable SPI settings the driver can apply
    • propagation delay for the internal delays of the driver (do you mean that with the "chip deadtime" mentioned above?)

    1. tDrive starts when GHx or GLx changes state. It starts when input going low, and it starts when input going high + deadtime + tdead
    So you mean that there is a reset for the t_drive, every time the logic input signal INxx toggles or the driver starts with the driving of a FET?
    This would mean using software deadtime, there are three resets of the t_drive, letting ist start from zero again? I tried to draw it in the figure below.


    In this second diagram, there would be two individual t_drive times, each reset once.


    Am I right with my current understanding here, with the t_drive time being reseted?




    • the deta time is the tdead=200ns. In this case, there is no dead-time insertion by the driver because software already added 1000ns. IOW, if you had programmed tdead=0 then the delta between cursors = 0s.
    You're telling that there is no dead time insertion by the driver, but why is the time marked by the cursor exactly the time t_dead?
    In my understanding there is no need for the DRV to use the 200 ns t_dead.
    My expectation is, that from the rising input signal INHx there would be a propagation delay and then the gate-source voltage highside (red) will start rising. I do not understand why the driver is using the t_dead here.

    Is there any state machine or flowchart describing the switching process in a bit more detail because also the figures in the datasheets aren't totally correct?

    Kind regards and thank you for you'r help
    Tobias

  • Hi Tobias,

    For some reasons - forum issue - I can't respond directly to your last post, so I will try to do that here.

    "propagation delay for the internal delays of the driver (do you mean that with the "chip deadtime" mentioned above?)"

    It includes the input digital delay + the deadtime inserted by the chip (not tdead that you add in SPI register) automatically to ensure no shoot through for the upper and lower FETs. Let's say the MCU switches INLx to low and INHx to high at the same time, then the output VGLx will go low immediately with tDrive delay, but VGHx only switches to high after VGLx is low, and this delay or deadtime is inserted by the driver internal logic, not by the user like you. Now if you add tDead to SPI register then the total propagation delay will be added with tDead.

    "So you mean that there is a reset for the t_drive, every time the logic input signal INxx toggles or the driver starts with the driving of a FET?
    This would mean using software deadtime, there are three resets of the t_drive, letting ist start from zero again? I tried to draw it in the figure below."

    Every transition on VGH or VGL has a tDrive with each transition of the signal which drives the FET gate. Why do we need to set the tDrive? 

    From datasheet:

    "The third component of the TDRIVE state machine implements a scheme for gate fault detection to detect pin-topin solder defects, a MOSFET gate failure, or stuck-high or stuck-low voltage condition on a MOSFET gate. This implementation occurs with a pair of VGS gate-to-source voltage monitors for each half-bridge gate driver. When the gate driver receives a command to change the state of the half-bridge, it starts to monitor the gate voltage of the external MOSFET. If the VGS voltage has not reached the correct threshold at the end of the tDRIVE period,, the gate driver reports a fault. To make sure that a false fault is not detected, a tDRIVE time should be selected that is longer than the time required to charge or discharge the MOSFET gate."

    So tDrive needs to be set in order for the driver chip to detect and flag a fault if the gate drive signal has not reached the correct voltage level at the end of the tDrive.

    "Am I right with my current understanding here, with the t_drive time being reseted?"

    tDrive cycle starts whenever the VGH or VGL making a transition. It is for each signal and not a total time for both signals.

    "My expectation is, that from the rising input signal INHx there would be a propagation delay and then the gate-source voltage highside (red) will start rising. I do not understand why the driver is using the t_dead here."

    The driver is using tDead here, because you told it to add tDead the the programmed 200ns in the SPI register.

    "You're telling that there is no dead time insertion by the driver, but why is the time marked by the cursor exactly the time t_dead?"

    Driver automatically insert deadtime (which is not the same as tDead in spi register) to ensure no cross conduction. In your case, since INH is delayed 1000ns after INL, and so there is no potential of cross conduction, and the driver knows this, and so it doesn't need to add any deadtime in this case. This is why I said you don't need to add software deadtime between the inputs. 

    "Is there any state machine or flowchart describing the switching process in a bit more detail because also the figures in the datasheets aren't totally correct?"

    section 8.3.1.4.2 and Fig 27 is the answer. 

    Brian