DRV8323: t_dead and t_drive with software deadtime (2)

Tobias Widmann said:

That's why I would expect a rising highside gate-source-signal (red) almost immediately after the change of INHx (Digital4), cause the t_dead should be already over. But in the measurements it seems, that the t_dead is added to the rising edge of the INxx input signal.

Can you please explain this to me a bit more detailed?

Hi,

Why wait 30 days later to bring this up? The original thread was closed because there was no activity for 30 days. I and others have to review the datasheet again to help you now.

About the 400ns delay from INH to GHx: I had pointed out that there are 2 kinds of deadtime: the driver automatic adding deadtime and the user deadtime using SPI. In this case, you wanted to add t-dead = 400ns, and this is exactly the delay from INH to GHx. This 400ns is not the driver own logic deadtime. Why don't you try with zero deadtime value to the SPI register and then see what the delay from INH to GHx is.

Brian

Hi,

unfortunately I was rarely in work last month, I'm sorry.

What I want to understand ist just, If the t_dead is always added to the software deadtime if the DRV want's to switch on a FET.
Does this even happen, when the t_dead should be already over?
Is the t_dead added to every switch on progress?

From the datasheet there is no further description when the digital dead time (t_dead / user deadtime) is inserted

Just setting the t_dead to zero is not possible for this driver in 6xPWM-Mode. So I need to know the timings to adjust the software deadtime.

Thank you for your help

Hi Tobias,

The following image from section 8.3.1.4.2 TDRIVE: MOSFET Gate Drive Control of the datasheet showcases the timing diagram for TDRIVE, which includes when the digital dead time being referenced (t_DEAD) is inserted. 

Best,

~Alicia

Tobias Widmann said:

What I want to understand ist just, If the t_dead is always added to the software deadtime if the DRV want's to switch on a FET.
Does this even happen, when the t_dead should be already over?
Is the t_dead added to every switch on progress?

Yes, t_dead is always added -- 50ns min for SPI and 100ns for hardware chip. With this understanding, why do you need to add more software deadtime such as 1000ns in your example? This wastes the total pwm range and causes distortion to the motor current.

I want to use a software deadtime because, depending on the used FET, the 2 V threshold for the deadtime insertion is not sufficient. It can happen, that the miller plateau occurs below the threshold value.

Refering to the updated state machine I would expect, that the t_dead only starts when the decreasing signal is falling below the 2 V threshold.

My expectation is the blue arrow in the picture below but in my measurements it seems that the t_dead is also added after signal changes of INxx (green arrow).
Do you have a description when the t_dead is added as I can't read it out of the datasheet.

red: gate-source highside
yellow: gate-source lowside
software deadtime: 1000 ns
t_dead: 200 ns
t_drive: 4000 ns

Tobias Widmann said:

Do you have a description when the t_dead is added as I can't read it out of the datasheet.

From datasheet:

"The first component of the TDRIVE state machine is automatic dead time insertion. Dead time is period of time between the switching of the external high-side and low-side MOSFETs to make sure that they do not cross conduct and cause shoot-through. The DRV832x family of devices uses VGS voltage monitors to measure the MOSFET gate-to-source voltage and determine the correct time to switch instead of relying on a fixed time value. This feature lets the dead time of the gate driver adjust for variation in the system such as temperature drift and variation in the MOSFET parameters. An additional digital dead time (tDEAD) can be inserted and is adjustable through the registers on SPI devices."

To verify this, I suggest you change software deadtime = 0 and spi t_dead=50ns, and then capture the same signals waveforms to analyze. 

Brian

Hi Tobias,

Section 2.2 Robust MOSFET Switching Through TDRIVE State Machine of the following App Note goes into more detail about the TDRIVE State Machine that is referenced in the datasheet for the DRV8323: Understanding Smart Gate Drive

Best,

~Alicia

Brian Dang said:

To verify this, I suggest you change software deadtime = 0 and spi t_dead=50ns, and then capture the same signals waveforms to analyze. 

If I reduce the software deadtime, the t_dead is inserted as expected. It starts when the falling gate-source voltage drops below the 2V threshold.

red: gate-source highside
yellow: gate-source lowside
software deadtime: 100 ns
t_dead: 200 ns
t_drive 4000 ns

That would correspond to the blue arrow in the measurement of 15th March 2023.

Hi Alicia,

thank you for the document. Refering to it it says:

"The internal handshaking uses VGS monitors of the external MOSFETs to determine when one MOSFET has been disabled and the other can be enabled. This handshaking lets the system insert an optimized dead time into the system without the risk of cross conduction."

This is also my expected behavior (blue arrow 15th March 2023) as the driver should insert the t_dead depending on the falling gate-source voltage. The measurement of 16th March 2023 with reduced software deadtime also shows this behavior.

I am wondering that it seems that the driver sets the t_dead also after the change of the INxx signal when using software deadtime. I have not yet found a document that explains this behavior.

The table below shows different t_dead settings in the SPI register with a software deadtime of 1000 ns.

t_drive:	4000 ns	4000 ns	4000 ns
software deadtime:	1000 ns	1000 ns	1000 ns
t_dead:	100 ns	200 ns	400 ns

I want / need to understand, why the t_dead is inserted here.

Regards,

Tobias

Hi Tobias,

Let me discuss this with my team, and I will aim to get back to you next week.

Best,

~Alicia

Tobias Widmann said:

I want / need to understand, why the t_dead is inserted here.

SPI t_dead is added always, so why the surprise here? If you don't want too much dead time, then set software dead to zero.

Brian.

Tobias Widmann said:

My expectation is the blue arrow in the picture below but in my measurements it seems that the t_dead is also added after signal changes of INxx (green arrow).

The blue arrow is not t_dead, as the input IH is still low. The blue arrow is part of the t_Drive = 4000ns time, notthing to do with dead time.

You cannot expect GHx to turned H at the blue arrow because HC input is still low which tells the driver to drive GHx low at that time.

Brian

Tobias Widmann said:

If I reduce the software deadtime, the t_dead is inserted as expected. It starts when the falling gate-source voltage drops below the 2V threshold.

red: gate-source highside
yellow: gate-source lowside
software deadtime: 100 ns
t_dead: 200 ns
t_drive 4000 ns

That would correspond to the blue arrow in the measurement of 15th March 2023.

The marker is wrong; it should be only 200ns so the first marker should be moved back to align with the grid.

No, this is not related with the blue arrow of the 3/15 pic which has the HC going H after the markers. If you reduce the t_dead=50ns then GHx will be turned on 150ns sooner as long as GLx is low.

Brian

Dear Brian,

Brian Dang said:

SPI t_dead is added always

can you please explain a bit more detailed what you mean with always.
What are the conditions that t_dead is applied?
The only conditions I know so far are:

• Falling gate-source signal below the threshold
• Input signal change from INHx 1, INLx 0 -> INHx 0 to INLx 1 or INHx 0 to INLx 1 -> INHx 1, INLx 0
• 6x PWM Mode, 3x PWM Mode or 1x PWM Mode needs to be selected

And just setting the software deadtime to zero is not always possible as already mentioned.

Tobias Widmann said:

If I reduce the software deadtime, the t_dead is inserted as expected. It starts when the falling gate-source voltage drops below the 2V threshold.

Regards

Tobias

Brian Dang said:

The marker is wrong; it should be only 200ns so the first marker should be moved back to align with the grid.

The picture with the cursors was created before I got to know the exact thresholds. So I understand why the selected t_dead differs from the measurement with the cursors.
https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1061056/drv8323-tdrive-mosfet-gate-drive-control

The intention of the blue cursor from 15th March 2023 was to show that t_dead, which should be only added (from my current understanding) when the gate-source voltage of the switching off FET is falling below the 2 V threshold, would have already expired when the input signal INHx changes. The thing I don't understand is why there is a 200 ns delay (green arrow) between the INHx change and the rising gate-source voltage (red), as I find no description for this behavior. That is the behavior I want to understand if I ask you if explain the always a bit more detailed.

Brian Dang said:

SPI t_dead is added always

Regards

Tobias

Tobias,

Whenever the user added t_dead using SPI, the driver must follow this wish and so it adds this t-dead after the input going H, regardless if the other input was already low in advance.

I think you still not clear of the difference between SPI t_dead and the dead_time that the driver adds based on the timing from one gate voltage going low to the other gate going high. Let's say for some reasons the going low FET takes 800ns to turn low (as your yellow GLx with 800ns fall time), and with no software deadtime, spi t_dead=500ns, then the chip will add more than 300ns dead time in addition of the 500ns before turning on the other FET.

Tobias Widmann said:

I am wondering that it seems that the driver sets the t_dead also after the change of the INxx signal when using software deadtime. I have not yet found a document that explains this behavior.

The table below shows different t_dead settings in the SPI register with a software deadtime of 1000 ns.

Tobias Widmann said:

I want / need to understand, why the t_dead is inserted here.

You're wondering why the chip sets the spi t_dead after the INxx signal rising. It's because the spi t_dead instructed the driver to add this t_dead after INxx and before before turning on the GHx.  

Tobias Widmann said:

I want to use a software deadtime because, depending on the used FET, the 2 V threshold for the deadtime insertion is not sufficient. It can happen, that the miller plateau occurs below the threshold value.

Of course one must do whatever to avoid shoot through condition, but I doubt that you have a FET that has threshold higher than 2v. 

Btw, the yellow GLx has 800ns t_fall which is too long. In general t_fall should be about 150ns by choosing Idrive properly, and t_rise should be not more than 300ns. Too long t_fall and t_rise will cause heat loss in the FETs.

Hello Brian,

thank you for this statement.

Brian Dang said:

Whenever the user added t_dead using SPI, the driver must follow this wish and so it adds this t-dead after the input going H, regardless if the other input was already low in advance.

To understand what you mean here I've marked your mentioned timings in the measurement.

Have I marked the times appropriately for your explanation or where do you see the timings in the measurement?

Brian Dang said:

I think you still not clear of the difference between SPI t_dead and the dead_time that the driver adds based on the timing from one gate voltage going low to the other gate going high. Let's say for some reasons the going low FET takes 800ns to turn low (as your yellow GLx with 800ns fall time), and with no software deadtime, spi t_dead=500ns, then the chip will add more than 300ns dead time in addition of the 500ns before turning on the other FET.

That would mean, that SPI t_dead is counting from the rising input signal INxx. When this timing is not sufficient, the DRV adds an additional dead time until the falling gate-source voltage passes the 2 V threshold.

Is then the SPI t_dead starting again after passing the 2 V threshold or where is the timing marked by the cursors coming from?

Can you please additionally tell me, if the timings t_drive and t_dead are starting with the change of the input signal INxx or when the DRV is starting to drive the gates (falling gate-source voltage)?

Brian Dang said:

Btw, the yellow GLx has 800ns t_fall which is too long. In general t_fall should be about 150ns by choosing Idrive properly, and t_rise should be not more than 300ns. Too long t_fall and t_rise will cause heat loss in the FETs.

Regarding the datasheet page 63-64 fall and rise time is calculated by using gate to drain charge. These pages refer to the switching edges of the output. Do you really recommend that the full charge of the gate should take only 300ns?

Hi Tobias,

t_RISE and t_FALL can be calculated using the following formula from section 1.5.1 Peak Gate Drive Current (Understanding Smart Gate Drive):

Tobias Widmann said:

Regarding the datasheet page 63-64 fall and rise time is calculated by using gate to drain charge. These pages refer to the switching edges of the output. Do you really recommend that the full charge of the gate should take only 300ns?

What is the Qgd of the MOSFETs that you are using? Also, what do you have your IDRIVE set to? 

Best,

~Alicia

Tobias Widmann said:

Is then the SPI t_dead starting again after passing the 2 V threshold or where is the timing marked by the cursors coming from?

Since the datasheet says spi t_dead is the additional delay time, so I would think it's added last before the Gate signal switched to H.

Tobias Widmann said:

Can you please additionally tell me, if the timings t_drive and t_dead are starting with the change of the input signal INxx or when the DRV is starting to drive the gates (falling gate-source voltage)?

t_drive starts when Gate signal rising or falling -- should be the same as INx switching.

Tobias Widmann said:

Do you really recommend that the full charge of the gate should take only 300ns?

Yes, otherwise too much heat in the linear region of the FET switching time. WE don't want too short (fast rise and falling cause EMI noise and ground bounce, but too long causes heat and distortion.

Brian

Dear Brian,

unfortunately we are not getting together on the point with the deadtime.
I do understand, why the t_dead is set after the switching off signal is falling below the 2 V threshold. That is also working fine in our application.

The main point we want to know is which additional options there are in the internal state machine, that the dead time is set.
For me the table from 16th March shows clearly that the time, marked by the cursors, is also dependent on the t_dead SPI setting.

t_drive:	4000 ns	4000 ns	4000 ns
software deadtime:	1000 ns	1000 ns	1000 ns
t_dead:	100 ns	200 ns	400 ns

You mentioned something like 

Brian Dang said:

Whenever the user added t_dead using SPI, the driver must follow this wish and so it adds this t-dead after the input going H, regardless if the other input was already low in advance.

which would match the behavior, but I don't know the conditions for this so far. I would expect to have something like this in the documents, the datasheet or at least in some forum article.

Tobias Widmann said:

The only conditions I know so far are:

• Falling gate-source signal below the threshold
• Input signal change from INHx 1, INLx 0 -> INHx 0 to INLx 1 or INHx 0 to INLx 1 -> INHx 1, INLx 0
• 6x PWM Mode, 3x PWM Mode or 1x PWM Mode needs to be selected

To the point of the switching time:
If I refer to the calculations provided by Alicia, which are also available in the datasheet, the switching current is calculated by the gate drain charge. 
I understand from the documentation that the recommended time (100 to 300 ns for charge) refers to the time it takes to provide the gate drain charge, not the complete gate charge. Doesn't that mean, that we meet this timing recommendation?

Thank you Alicia,

now we are getting together.

Alicia Rosenberger said:

In cases where the user inserts a software deadtime that would exceed the automatic deadtime insertion feature, the software deadtime added by the user would, essentially, be used in place of this feature. However, as with the use of automatic deadtime insertion, _tDEAD will be added in addition to the software deadtime as t_DEAD will always be added to the device.

Just one more thing.
If the software deadtime is ending almost the same time, the gate-source voltage is falling below the threshold, is then the t_dead always applied from the condition which is fulfilled last?

So in case of this picture, where software deadtime (red) and threshold (blue) are almost at the same time, the blue arrow is applied?

Thank you for you'r help
Tobias