DRV8711: Overcurrent Protection (OCP) and long VDS rise time

Hi REMI,

Thank you for posting to the motor drives forum.

Let us take some time to research your question and we'll get back to you with a reply by 12/04 US time

Hi REMI,

We are going to begin investigating this issue.

In the meantime I have a few questions for you.

1. Can you provide a scope screenshot showing A-phase current, A1HS, AOUT1, and nFAULT. Make sure to set the trigger source as a negative edge of the nFAULT signal (nFAULT will drop to 0V when the OCP fault is triggered). Zoom in close enough so that the rise time is visible.
2. Did the device resume operation after the fault was triggered? Did you have to reset the device to clear the fault?
3. Were you able to recreate the OCP fault more than once on each of the failing units? 
4. Just to confirm, the parts you listed above make up the 50 units that were triggering OCP?

Hi Pablo,

thank you for considering my case. You can see below answers to your questions:

1. standby until (a) cursor, then motor rotation until (b) cursor when X BOCP error is trigged:

CH1: note connected; CH3: B phase current; CH4: A phase current

Zoom and FAULTn signal added:

CH1: FAULTn; CH3: B phase current; CH4: A phase current

BOCP error trigged at the right of the screenshot:

CH1: B1HS; CH2: B2HS; CH3: B phase current

2. Operation resumes by switching off the power supply. I have no direct access to FPGA registers.

3. Concerning a particular defective board, the OCP fault occurs exactly at the same motor position, when current in the incriminated phase become positive or negative (it depend on the MOSFET of the H bridge that present a longer rise time).

board n°0105 FAULTn when CH4 current rise positive

board n°1016 FAULTn when CH4 current rise positive

board n°1152 FAULTn when CH4 current rise positive

4. At the moment only 20 defective boards are in my hands. But all of them have the marking you can see on the pictures of my first post.

Best regards,

Additional test results:

1. Bellow measured rise times and fall times:

There are 3 stepper axis on this board. it depends on the boards, but each axis and each phase can be concerned by this issue.

If an error is triggered, it always leads to a longer rise time measure on the indicated phase.

2. Oscilloscope screenshots for different DRIVE parameters (FAULTn connected to 1st digital probe):

Standard mass prod parameters:

00 --OCP     OCP threshold

00 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

CH3: B phase current; CH4: A phase current

CH1: A1HS; CH2: AOUT2; CH3: A2HS; CH4: A phase current

00 --OCP     OCP threshold

11 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

00 --IDRIVEP High-side gate drive peak current

CH1: A1HS; CH2: AOUT2; CH3: A2HS; CH4: A phase current

Zoom:

CH1: A1HS; CH2: AOUT2; CH3: A2HS; CH4: A phase current

00 --OCP     OCP threshold

11 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

10 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

00 --IDRIVEP High-side gate drive peak current

CH1: A1HS; CH2: AOUT2; CH3: A2HS; CH4: A phase current

00 --OCP     OCP threshold

11 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

11 --IDRIVEP High-side gate drive peak current

CH1: A1HS; CH2: AOUT2; CH3: A2HS; CH4: A phase current

3. Endurance test in progress

00  --OCP     OCP threshold

01  --OCPDEG  OCP deglitch time

01  --TDRIVEN Low-side gate drive time

01  --TDRIVEP High-side gate drive time

01  --IDRIVEN Low-side gate drive peak current

01  --IDRIVEP High-side gate drive peak current

These parameters seams better. But the question is why we have to change the settings after months of good working? And is the DRV8711 was damaged, and will fail again using these alternative parameters during other months?

Rds,

Hello,

Please give us another day to investigate this.  

Hi REMI,

Thank you for your patience.

I am contacting our Quality team to check the date codes of the parts you listed to see if there are any issues. Could you also provide me with date codes of parts that are behaving properly?

Could you also increase the OCP to 750mV (OCPTH=01) on a failing unit and redo your experiment. Is the issue with the OCP still present?

I will reply to this thread once I hear back from the Quality team. Expect a reply from me by 12/10 or earlier.

Hi Pablo,

Same date codes are fine on some other boards, or on same boards considering other stepper axis are still ok on defective boards (each board includes 3 axis).

To increase OCPTH to 750mV do not help solving this issue.

Rds,

Hi REMI,

Thank you for the information. 

To make sure I understand clearly, are you saying that parts with the same date code works on some boards and does not work on others? So the following date codes will fail in some boards but not on others?:

1. 83TG4 CGLY
2. 82TG4 CPYH
3. 82TG4 CPYJ

Also, I'm having some difficulty understanding what you mean by "considering other stepper axis are still ok on defective boards (each board includes 3 axis)" can you clarify what you mean by "axis"?

By the way, I already reach out to the quality team and will let you know once I hear from them. In the meantime, I will look through all the data you have provided. Expect an update from us by 12/10.

Hi Pablo,

Our boards includes 3 stepper motor axis powered by three DRV8711.

Over 50 defective boards, some of them have been working fine for months before failure:

• Minimal TTF= 1.2 months
• Average TTF= 14.1 months
• Maximal TTF= 26.4 months

A board is considered as defective as soon as 1 over 3 axis has an issue. 2 other axis remaining (with same date code) would maybe work fine until end of life of the machine…

So it is difficult to know which date code will really be ok for years…

Rds,

Hi REMI,

We researched the lot trace codes of the parts in question. No issues were found with these parts.

Allows us more time to research further and we'll get back to you by 12/14 with an update. In the meantime, if you have any new information or data that you can share with us it would be of great help.

Hi REMI,

I looked through the information and waveforms you provided. I noticed you have try multiple values for the OCP threshold and OCP deglitch time. However, I'm interested in seeing tests results when OCP Threshold and OCP deglitch time are set to the max (11). My thinking here is that your current configuration with OCP threshold and deglitch time is causing a very narrow marginal line where in some instances it triggers OCP and in some cases it doesn't. Can you provide data with OCP threshold and deglitch time both set to 11.

The way that this device monitors for OCP is by monitoring the VDS of each FET and triggering the Fault once it detects the value go above the user set threshold for the deglitch duration time set by the user. For the High side FETs, the driver monitors the VDS by monitoring the voltage between VM (pin 4) and XOUTY. This means that if there is any difference in voltage between VCC_MOT connected near the Drain of the High-side FET in question and the VCC_MOT in pin 4 (VM) of the driver, the driver can trigger an OCP fault despite the VDS value across the FET being below the threshold value. For example, if the voltage at the Drain pin of the FET is lower than the voltage at VM pin, the OCP monitoring circuitry will measure a higher VDS value (since it only measures between VM (pin 4) and XOUTY) than the actual VDS value of the FET resulting in false OCP. In case that the OCP threshold is set too low, you may observe false OCP faults if the VCC_MOT of the H-bridge and the VCC_MOT of the device show a slight difference in voltage values. Can you redo some of your tests and measure the voltage near the H-bridge supply and the voltage near pin 4 (VM) of the device. Make sure to include the nFAULT signal in the scope shot.

The other piece of information I found puzzling was UVLO faults happening in some of the boards. Were you able to figure out the cause of the UVLO faults? It only seems to happen on the Z axis. I wonder if maybe during OCP, the power supply voltage is pulled down below the UVLO threshold. What is the VM supply voltage? Can you redo a test and show the supply voltage during an OCP fault on one of the boards experiencing UVLO?

Let me know if you need me to clarify my statements above. 

Hi Pablo,

Standard parameters as reminder:

00 --OCP     OCP threshold

00 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

00 --IDRIVEP High-side gate drive peak current

We have already tried to set maximum OCP threshold and deglitch time (11 both) on board SN1152, but it is not better:

11 --OCP     OCP threshold

11 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

00 --IDRIVEP High-side gate drive peak current

=> NOK

But OCPDEG=01 helps only if associated to longer drive times (TDRIVEx):

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

11 --TDRIVEN Low-side gate drive time

11 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

00 --IDRIVEP High-side gate drive peak current

=> spot test OK

As explained in previous post, we have started machine endurance tests:

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

01 --IDRIVEN Low-side gate drive peak current

01 --IDRIVEP High-side gate drive peak current

=> One board still ok after 6 days

=> Two boards still ok after 10 days

=> One board fail after 3 days

As above parameters has failed (for one board), we are now testing this new parameters set:

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

10 --TDRIVEN Low-side gate drive time

10 --TDRIVEP High-side gate drive time

01 --IDRIVEN Low-side gate drive peak current

01 --IDRIVEP High-side gate drive peak current

=> 4 boards have been running for 1 day…

Regarding UVLO, only 3 boards over 20 boards available in the lab at the moment have UVLO (each time for Z axis).

If we look at the errors saved in the log by the firmware, these events are rare compared to OCP error in the same board:

 Anyway, we will carry out tests tomorrow on the DRV8711 dedicated to Z axis with SN0633 board, measuring:

• H-bridge supply
• voltage near pin 4 (VM)
• FAULTn

 The AC/DC power supply is Meanwell EPP-200-48

 Have a look at the 6 layers layout (nets from power supply input connector to VM pin 4 are blue highlighted):

 BR,

Hi REMI,

Thanks for providing the information. 

Your layout looks okay. I'm not seeing any issues with it that could explain the OCP triggers you are observing. I think if bad layout design were to be the culprit here, then the issue would be observed in many more units.

All the data you provided is very useful so let us take another day to research and come up with other explanations for the issue you are facing.

Hi Pablo,

To go to the end with UVLO analysis, we measured board SN0633.

Reminder:

• most of the time X axis AOCP or BOCP
• sometimes Z axis UVLO

Channel 2 and 3 with the same offset on the screen.

Vac and math channel:

That confirm there is no significant voltage drop between H-bridge supply and VM pin 4.

We noticed that UVLO for Z axis is only trigged associated to X axis OCP and in case of cold start, but not when CPU is rebooted through Reset switch. So it could be related to SPI decoding for example.

Next step we will focus on TDRIVE and IDRIVE behavior.

Rds,

Board SN 1189 has Y AOCP error.

OCP threshold and deglitch time both set to 11 are not better

Spot test OK with the following parameters:

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

11 --TDRIVEN Low-side gate drive time

11 --TDRIVEP High-side gate drive time

00 --IDRIVEN Low-side gate drive peak current

00 --IDRIVEP High-side gate drive peak current

Rise times and fall times measured with the parameters above:

=> Y AOCP error confirmed by the long rise time get for AOUT1

For the bad MOSFET driver A1HS (red zone) and for a good MOSFET driver B2HS (green zone), serial gate resistors (R210 and R213) have been removed and remplaced by a looped wire to be mesured with current probes:

Cursors according to xDRIVEP settings:

Cursors linked to the curves:

Cursors according to xDRIVEP settings:

Cursors linked to the curves:

=> Why does the sourcing current of this MOSFET Q15 is quite similar to the current for Q18, but the rise time is really longer?

=> Is the DRV8711 internal current generator involved?

Next data with the following parameters:

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

01 --TDRIVEN Low-side gate drive time

01 --TDRIVEP High-side gate drive time

01 --IDRIVEN Low-side gate drive peak current

01 --IDRIVEP High-side gate drive peak current

Cursors according to xDRIVEP settings:

Next data with the following parameters:

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

10 --TDRIVEN Low-side gate drive time

10 --TDRIVEP High-side gate drive time

10 --IDRIVEN Low-side gate drive peak current

10 --IDRIVEP High-side gate drive peak current

Cursors according to xDRIVEP settings:

At the moment, according to the endurance tests, best parameters to make work defective boards are the following:

00 --OCP     OCP threshold

01 --OCPDEG OCP deglitch time

10 --TDRIVEN Low-side gate drive time

10 --TDRIVEP High-side gate drive time

01 --IDRIVEN Low-side gate drive peak current

01 --IDRIVEP High-side gate drive peak current

What is the disadvantage to increase TDRIVEx (from 01 our standard settings to 10)? Is there side effect?

BR,

Hi REMI,

Looking at the last oscillograms I can say that sourcing current on Q15 gate is a bit lower than on Q18 so RT on Q15 is a bit longer too.

If the boards were working OK at the beginning, then problems arised but replacing DRV8711s solved these problems I would think

DRV8711s were damaged somehow.

If the problems are just with HS drivers then they might be caused by VM overvoltage.

There are no visible spikes or ringing on voltages at oscillograms so PCB design is not rather a problem.

The only sources of overvoltages I can think of are those caused by motor resonances and uncontrolled stops from high speed.

I would keep on doing endurance tests but every time I would change something, like:

- adding big cap to VM like 4700uF,

- lowering VM by 5-10V,

- adding LS gate resistors

and I would monitor VM all the time for MAX value.

Best Regards,

Grzegorz

Hi REMI,

Thank you for providing the information.

Below are answers to your questions:

Q1: Why does the sourcing current of this MOSFET Q15 is quite similar to the current for Q18, but the rise time is really longer?

A1: The rise and fall time (slew rate)  is depended on the gate current (or IDRIVEx) and the Q_gd (gate-to-drain charge) of the FET. The rise time will be equal to G_dg/I_source. The plot below shows the turn-on response of the FET. As you can see, the VDS voltage slew rate occurs during the miller region which is depended on the Q_gd. Then one explanation for the difference in slew rate between the two is likely due to difference in the Q_gd value between the two FETs. You can learn more about smart gate driver in this app-note.

Q2: Is the DRV8711 internal current generator involved?

A2: The internal pre-driver gates source the IDRIVE current set by the user. The slew rate is affected based on the IDRIVE setting as explained in my previous answer. 

Q3: What is the disadvantage to increase TDRIVEx (from 01 our standard settings to 10)? Is there side effect?

A3: Increasing TDRIVE will increase the time when Idrive is being sourced to the FET as shown in the diagram below. The one advantage of longer TDRIVE is that it can allow the FET to have enough time to fully turn on. If the TDRIVE is too short, the FET may not have enough time to turn on and a gate driver fault may be triggered. The  gate drive fault is there to ensure that under abnormal circumstances, such as a short on the MOSFET gate, the high peak current through the driver and MOSFET gate is limited to a fixed duration. The one disadvantage of increasing TDRIVE is that if a short has occured in the FET, Damage could occur to the FET or driver since it longer time needs to pass before the gate-drive fault is triggered. The plot below shows a TDRIVE example. 

Hi REMI,

In the previous waveforms you sent, did the OCP faults disappeared after increasing IDRIVEP and IDRIVEN? It could be possible that during FET turn-on, when the rise time is longer, the FET might be on a high RDS-on state causing the voltage drop across the FET to be higher than the OCP threshold. The data you collected seems to back this up as the OCP fault seems to occur when rise time is longer. 

Have you tried increasing the IDRIVE in one of the faulty boards and has that removed the fault? 

Hi REMI,

Any updates from your side? Were you able to figure out the root cause of the OCP faults?

Hi Pablo,

Yes, to increase TDRIVE and IDRIVE remove the fault of faulty boards, but only for a short times!

Indeed, endurance has shown that these parameters are better: with old parameters, faulty boards failed at first attempt whereas the new parameters works for a couple of days of continuous axis moving.

I’ll post today screenshots regarding high voltage spikes, but I’m afraid that is not really relevant…

BR,

Rémi

Remi,

Thank you for the update.

For future testing, I also recommend trying different FETs. Preferably, FETs with lower Q_GD (gate-to-drain charge). As I mentioned in one of my previous replies, the rise/fall times is inversely proportional to IDRIVEX and directly proportional to the Q_GD. So for a given IDRIVE, a FET with lower Q_GD will result in shorter rise/fall times.

I just want to mention that this thread has been open for quite some time. If possible, I would like to close this thread soon. If you require further help, you may ask a new related question.

Hi Pablo,

Yes, this thread is opened for some time but unfortunately the issue still exist and number of defective boards continuously increase!

Sure, changing FETs for lower Q_GD will reduce rise/fall times as well as increasing IDRIVE setting values (although this way would be easier for an existing board).

But the point is to understand and avoid the fact the rise time increase all along life cycle of the boards.

What could lead to lowering the current level provider by pre driver?

Rds,

Hi Grzegorz,

Thank you for your advice.

Overvoltages were also a way that we wanted to explore and your message led us to proceed at some tests.

On a moving machine at maximum speed, we:

- stop movements thanks to the stop command => negligible spikes

- stop physically axis => negligible spikes

- disconnect stepper motor wires => that leads to more significant voltage spikes

Following screenshot when axis phisically stopped (FAULTn has never been trigged):

Following screenshot when a stepper motor is disconnected (FAULTn has never been trigged) :

The DRV8711 maximum voltage is 60V, so we started a burning endurance test at 60V. We measured short rise times on each high side FETs for each 3 motors axis (12 FETs for a board). So will compare these rise times after days on runing.

Rds,

Rémi

Hi Remi,

Thanks for your answer.

My application is probably different from yours but maybe it would be helpful.

I run Nema 24 and 34 motors with currents up to around 10A, I also made tests with currents up to 20A at 48VDC.

At the beginning I destroyed a couple DRV8711s and Mosfets on EVM boards, they were catastrophic failures.

I found TI notice about low side gate resistors and after using 56Ohm on all low side Mosfets my problems ended.

I noticed also some problems that could cause failure.

With 4700uF bulk cap I noticed that during low speed resonance I had overvoltages at VM around 3V for about 10ms (not a big problem).

After stopping motors from speed above 2000-3000 rev/min VM was able to go well beyond 60V for 200-500ms so I decided to use brake chopper.

The last thing that I minimized were switching spikes and ringing (about 100MHz) that could cause excessive EMI and negative overvoltages at ISENP pins.

That I done with several decoupling MLCC caps in range of 10nF - 2,2uF on VM and by minimizing parasitic inductances on PCB (4-layer board with ground plane).

I haven't had any problems for the last 2 years (testing on the bench and run on machine) but it was only two boards (the same mosfets as on EVM).

If you have Z axis that weights over let say 1kg and can back drive motor by ball screw or belt I would check if it can go down on its own and

rise voltage on VM over 60V.

Your case is very interesting because its not a catastrophic failure and happens not very often.

Best Regards,

Grzegorz

Hi Grzegorz,

Thank you for you comments. Your case is also interesting. Your problem was fixed by adding gate resistors to increase the rise time. However, in Remi's case, it seems like a high rise time is what is causing their problem.

Remi,

I will keep this thread open and will work with you to try and find the root cause of the rise time over time.

I don't think the voltage spikes is causing the problem in your case. If this was the case, I would suspect that the damage would occur more frequent. One possible explanation I can think of is that the gate trace resistance is somehow increasing when you perform the stress tests. How exactly are you performing these stress tests? Do you keep the motor running for very long time (days perhaps)? Maybe the temperature increase is causing the resistance to increase which will make the rise time increase.

Please let me know once you finish the 60V endurance tests. I'm interested in looking at those results.

Hi,

I can only guess that increased rise time is caused by DRV8711 damage (after replacing DRV8711 rise time goes back to normal,

that was mentioned in first post by Remi in this thread). 

I took a look at BUK7Y15-60E datasheet, its Crss/Ciss ratio is not very good (comparing to CSD18531), it may cause shoot through.

It would be good to check if low side mosfet gates are kept low while switching high side mosfets on.

Its just another guess.

Best Regards,

Grzegorz

Hi Grzegorz,

Thanks again for your input.

I am agreement with you that we should look at the low side MOSFETs gates during switching. There could be some shoot-through occurring.

Remi,

For future testing, you can measure the gate voltage of both High and Low side MOSFETs of a failing unit.

Hi all,

Here is the description of the defective board n°633:

Failures reported by customer after 7 months using the machine (with our standard parameters):

00 OCPDEG

01 TDRIVEN

01 TDRIVEP

00 IDRIVEN

00 IDRIVEP

=> X AOCP + X BOCP + Z UVLO (rarely)

Failure after endurance test during one month in a machine moving continuously X and Y axis (no Z axis option for this machine):

01 OCPDEG

10 TDRIVEN

10 TDRIVEP

01 IDRIVEN

01 IDRIVEP

=>  X AOCP after one month (then error occur at each motor rotation)

Rise times and fall times measured before and after one month endurance with the following parameters:

01 OCPDEG

11 TDRIVEN

11 TDRIVEP

00 IDRIVEN

00 IDRIVEP

=>  X AOCP

=>  No significant change in rise/fall times before and after one month endurance, despite the systematic occurrence of the error X AOCP.

Oscilloscope screenshots below with same parameters used for rise and fall times measurements.

FAULTn occurs when current fall to 0 at white cursor at top right

Hi Remi,

Looking at first oscillogram I noticed some peaks at A1LS during switching on high side mosfet, they have amplitude around 1V.

Is it enough to switch LS mosfet on, probably not. minimum threshold voltage for BUK7Y15-60E at 100C is around 1.7V.

But it's quite close, the peak would be probably higher for higher IDRIVEP values and for shorter TDRIVEN values (the peak is now within 2us time

from switching LS mosfet off).

I would keep TDRIVEN = 11, TDRIVEP = 11, IDRIVEP =00 but I would try to increase IDRIVEN value and watch if peak at LS Mosfet gates decreases.

I would do that for good boards and see if it helps to reduce failures or not.

Next step would be adding some capacitors between source and gate of LS mosfets or replacing them for ones that have better Crss/Ciss ratio.

I would focus more on what is going on with good boards before problems arise with long rise times and errors.

Best Regards,

Grzegorz

Hi Remi,

Thank you for providing the detailed information.

Looking at the 4th plot from the top, there is a region of around 2µs where both A2HS and OUT2 drop in voltage before OUT2 drops to 0V. I would like to understand why this is happening. As I mention in one of my previous replies, the driver triggers an OCP fault when the Vds of a particular MOSFET goes above the set OCPTH value for more than OCPDEG (2µs in your case). If VM is staying constant during this period, the apparent Vds value will be far above the 1V max threshold. I think this may be what’s causing the OCP fault since the time period of this region is around 2µs which is the OCP deglitch time.

The other question is what is causing the drop in both AOUT2 and A2HS. VM may be decreasing during this period causing the charge pump (VCP) voltage to decrease. A2HS is tied to VCP when enabling the HS FET so if VCP decreases, A2HS will also decrease.

To verify if my thinking is correct, can you retake this waveform but included VM, VCP, A2HS, and AOUT2. Make sure to zoom in to the region where the OCP is triggered. Also add a math function to measure the difference between VM and AOUT2 voltage.

Hi Pablo,

Below additional measures with same board n°633 as in my previous message:

=> VM-AOUT2 is about 800mV (OCPTH=250mV) 2µs before FAULTn is trigged.

=> At normal operation, A2HS is 48+10=58V (cursor a), but it decrease suddenly and the FET is not driven anymore when A2HS voltage is below 48+3.6V=51V (cursor b) as VGSth is typically 3V for BUK7Y15-60E.

=> VM and VCP stay stable, however A2HS decrease…

There are other situations where A2HS decreases before FAULTn is trigged:

Occurrence when FAULTn goes low:

=>  Vgs almost reaches Vgsth typ. (51.2-48=3.2V #3V)

Occurrence just before FAULTn goes low:

 =>  Vgs stays above Vgsth typ. (52.8-48=4.8V > 3V)

Adding A2HS gate current measurement:

Other phase with normal rise times to compare:

BR,

Rémi

Hi Remi,

Thank you for providing the detailed waveform. Below are some of my comments:

• The sections of longer drive time (areas where AOUT2 is HIGH for longer time) is due to the driver moving to the next STEP. While transitioning to a STEP of higher current level, like in your case,  the driver will typically keep the output ON until the current reaches the ITRIP value of that STEP. From the waveform, it is clear that right before the nFAULT triggers, OUT2 is ON for much longer time compare to previous times. The longer OUT2 is HIGH, the more A2HS decreases until it turns off the FET which triggers the OCP.
• The next step will be to investigate what is causing A2HS to decrease the longer the HS-FET is enabled. It would be interesting to see a side by side comparison between a "good" IC and a "bad" IC to observe if the A2HS decrease can be seen in the "good" IC as well. For a more fair comparison, I suggest using the same PCB with same FETs but only change the driver IC.
• One possible solution that may solve this OCP issue is by choosing FETs with lower VGS_TH. Is that something you can do?

Hi Remi,

Any updates from your side?

Hi Pablo,

Unfortunately, board n°633 was destroyed while replacing the defective DRV8711… So, we can’t compare the measures of the previous post with the same board and a new DRV8711.

That why we had to select the defective board n°557.

Failures reported by customer after 7.5 months using the machine (with our standard parameters):

00 OCPDEG

01 TDRIVEN

01 TDRIVEP

00 IDRIVEN

00 IDRIVEP

=> X AOCP (each time at the same indexer position)

Rise times and fall times measured with the following settings (to avoid OCP errors at each tests)

01 OCPDEG

11 TDRIVEN

11 TDRIVEP

00 IDRIVEN

00 IDRIVEP

All oscilloscope screenshots below with standard parameters.

Driver outputs concerned by OCP error (X AOCP):

=> FAULTn goes down at (b) cursor

=> gate voltage grows abnormally slowly

Charge pump voltages measurement:

VM=58V

CP1 max=11.6V

CP2 max=60.8V

T_CP=2.5µs => f_CP=400kHz

=> charge pump behavior seems to be ok

/!\ when measuring charge pump voltages, the OCP error mainly disappears (and is now only observed sometimes).

Same as first screenshot but without OCP error:

=> as when OCP error occurs, the gate voltage also slowly rises to its nominal voltage.

Other bridge with normally short V_DS rise times and no OCP error:

=> the gate voltage is fine

I really hope these test results could help understanding what is wrong.

However, we have limited resources within the team and unfortunately the issue is very serious. Each additional test requested takes days and we really need to solve this trouble! Can we send to you a defective board and a basic test kit (including stepper motors and harness cable) for further analysis in your lab? Or even consider advanced support with a TI specialist coming to work on our site a couple of days?

Many thanks in advance for your help.

Remi

Hi Remi,

Thank you for providing the update.

 I will look through the data thoroughly to try to see if I can find the root cause. In the meantime, I will see what we can do about testing your board in our lab. I'll let you know once I have more information.

We'll work closely with you to try and solve your issue as soon as possible. Thanks for your patience in advance.

Expect a reply from me by 2/5 or earlier.

Hi Pablo,

Same board n°557 as previous message.

The DRV8711 of X motor axis has been replaced by a brand-new part.

=> There is no X AOCP error anymore

Now we could compare waveforms using DRV8711EVM with following settings:

DRV8711_CTRL D21

DRV8711_TORQUE         155

DRV8711_OFF   028

DRV8711_BLANK             040

DRV8711_DECAY             214

DRV8711_STALL               800

DRV8711_DRIVE              050

DRV8711_STATUS           000

Then we will remove the EVM driver and replace it with defective driver from the board n°557.

BR,

Rémi

Hi Remi,

I apologize for the late response. I was out of the office on 2/5.

Please let me know the test results of replacing the EVM driver with the faulty driver. The results will help us determine if the OCP issue is being caused by the driver or by the board design.

I'm still talking with my management if we can debug your board on our lab. There is a process we have to follow for this type of situations so I will let you know once I have more information.

Going back to the recent waveform you provided, it looks like the A2SH signal is inverted compared to the same signal from board # 633 (shown below). In board 557, the A2SH signal slowly increases. this is observed in the case of the faulty driver. On the other hand, the A2SH signal goes up to its max value and slowly decreases until the increasing VDS of the HS FET triggers the OCP fault. I'm not quite sure what the reason for this difference is. Could be due to differences between the two boards.

Also, something weird is happening with the charge pump it seems. When measuring it, you don't see the OCP issue despite the slow A2SH increase. I will look into this. the slow increase of the A2SH could be cause by an unstable charge pump. Looking at all the data you have provided, it seems like the OCP is triggered almost every time the AxSH signal is not stable.

I will continue to investigate and will have some new information for you by 2/10 or earlier.

Hi Pablo,

I will not be able to carry out test with EVM before 11/10.

Meanwhile you could maybe have a look at the BOM parts (for X et Y axis):

I’m not sure the charge pump is directly involved because we measure very stable values around the charge pump, even when error Is trigged. Moreover I guess every high side drivers should be concerned in case of charge pump issue.

I wonder if it not related to the driver stage in charge of current regulation (sink and source).

I really hope you will find a way to investigate with physical boards.

Can we discuss this by email?

BR,

Hi Remi,

I looked through the BOM. Everything looks in order. No obvious issues.

If you have any information you would like to share with me privately, you can send me a private message by hovering over my name and clicking on send private message. What you send will only be visible to me.

We can talk via private message if you have information you don't want to share with the public forum.

Hi Pablo,

As previously discussed, we soldered the defective DRV8711 from the board N°557 to the EVM.

Part removed from board N°557:

EVM with original part                                                              

EVM with part from board N°557

Please note there is something wrong with .cfg configuration file used by DRV8711 EVM GUI (Version:1.0.0.299, Build - 04/26/2017) to backup settings.

-          It writes DRV8711_DECAY           214 (corresponding to fast decay)

-          instead of DRV8711_DECAY        514 (for auto mixed)

When loading .cfg configuration file, then we always manually set decay mode.

Anyway, all measures on EVM are carried out in “auto mixed decay at all the time” as for our board.

Bridge with abnormal behavior (and A OCP error when starting test on the customer board):

=> long rise time and low Vgs max (A2HS)

Other bridge with normal behavior:

=> shorter rise time, and higher Vgs max (A1HS)

BR,

Rémi