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.

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

Part Number: DRV8711

Hello,

 

Some of our boards using the DRV8711 trigs OCP errors (50/2000 boards).

These boards operate normally few months, then errors happens every time at the same motor position (ie: when A phase become positive)

 

For each boards concerned by this issue, we measure abnormally long rise time at the output of one high side MOSFET (more than 300ns when all other are less than 180ns).

 

Below our standard DRIVE register 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

00 --IDRIVEP High-side gate drive peak current

 

Using these new parameters improve but the issue still exist:

01 --OCPDEG OCP deglitch time

11 --TDRIVEN Low-side gate drive time

11 --TDRIVEP High-side gate drive time

 

No change when we replace the MOSFET.

But rise time is then fine after replacing the DRV8711 by a brand new.

 

See attached schematic CN6-22D_SCH_DRVX+Z.pdf

 

See attached oscilloscope screenshots from the same board:

  • X axis_Q24 MOSFET_bad DRV8711.png è rt=311ns

  • X axis_Q24 MOSFET_brand new DRV8711.png è rt=165ns

 

How to explain the rise time has increased since the beginning of the life cycle?

 

Below part marking of the DRV8711 concerned by the issue:

83TG4 CGLY (see attached picture 102X.jpg)

82TG4 CPYH (see attached picture 590X.jpg)

82TG4 CPYJ (see attached picture 763X.jpg)

Could you detail date code and numbering and confirm these parts are right?

 

Any suggestion, workaround, explanation?

Many thanks in advance

  • 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:

    board serial number

    error

    axis

    rt AOUT1
    (ns)

    ft AOUT1
    (ns)

    rt AOUT2
    (ns)

    ft AOUT2
    (ns)

    rt BOUT1
    (ns)

    ft BOUT1
    (ns)

    rt BOUT2
    (ns)

    ft BOUT2
    (ns)

    DRIVE parameters

    27

    X AOCP

     

     

     

     

     

     

     

     

    102

    X BOCP + Z UVLO

    180

    75

    165

    75

    165

    70

    265

    75

    105

    Z BOCP

     

     

     

     

     

     

     

     

    194

     

     

     

     

     

     

     

     

    217

    Y AOCP + Y BOCP

     

     

     

     

     

     

     

     

    500

    Y BOCP

     

     

     

     

     

     

     

     

    674

    X AOCP + Y BOCP

    X

    333

    95

    177

    77

    196

    92

    182

    79

    new

    674

    X AOCP + Y BOCP

    Y

    210

    101

    170

    78

    260

    76

    187

    99

    new

    763

    X BOCP

    X

    194

    114

    244

    142

    197

    105

    308

    105

    new

    763

    X BOCP

    Y

    243

    131

    206

    103

    292

    136

    210

    110

    new

    1016

     

     

     

     

     

     

     

     

    1152

    X AOCP

     

     

     

     

     

     

     

     

    136

    X AOCP

    X

    300

    101

    175

    72

    178

    85

    185

    74

    new

    136

    X AOCP

    Y

    192

    93

    176

    74

    185

    71

    190

    77

    new

    136

    X AOCP

    Z

    183

    74

    175

    75

    180

    73

    188

    72

    old

    632

    Y AOCP + Z UVLO

     

     

     

     

     

     

     

     

    1081

    X AOCP + Z AOCP

     

     

     

     

     

     

     

     

    527

     

     

     

     

     

     

     

     

     

    590

     

     

     

     

     

     

     

     

    939

    Z AOCP

     

     

     

     

     

     

     

     

    734

    no error

    X

    188

    93

    170

    75

    179

    99

    175

    79

    old

    734

    no error

    Y

    173

    90

    165

    77

    160

    76

    186

    78

    old

    734

    no error

    Z

    162

    79

    160

    75

    160

    73

    166

    72

    old

    633

    X AOCP + X BOCP + Z UVLO

    X

    180

    77

    275

    76

    168

    77

    280

    77

    new

    633

    X AOCP + X BOCP + Z UVLO

    Y

    185

    80

    170

    78

    161

    80

    178

    80

    new

    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:

    board serial number

    number of Z UVLO errors saved in the log

    number of OCP errors saved in the log

    102

    3

    24

    632

    13

    90

    633

    12

    17

     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

     

     

    CH1

    FAULTn

    CH2

    VM DRV Z

    CH3

    H-bridge supply

    CH4

    I phase A

     

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

     

    Vac and math channel:

     

    CH1

    FAULTn

    CH2

    VM DRV Z

    CH3

    H-bridge supply

    CH4

    I phase A

     

    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:

    board serial number

    error

    axis

    rt AOUT1
    (ns)

    ft AOUT1
    (ns)

    rt AOUT2
    (ns)

    ft AOUT2
    (ns)

    rt BOUT1
    (ns)

    ft BOUT1
    (ns)

    rt BOUT2
    (ns)

    ft BOUT2
    (ns)

    1189

    Y AOCP

    X

    169

    72

    176

    77

    167

    80

    167

    73

    1189

    Y AOCP

    Y

    315

    80

    165

    74

    165

    71

    162

    71

     

    => 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:

    CH1

     

    CH2

    S Q18

    CH3

    I phase B

    CH4

    I g Q18

    Cursors linked to the curves:

    CH1

     

    CH2

    S Q18

    CH3

    I phase B

    CH4

    I g Q18

    Cursors according to xDRIVEP settings:

    CH1

     

    CH2

    S Q15

    CH3

    I phase A

    CH4

    I g Q15

    Cursors linked to the curves:

    CH1

     

    CH2

    S Q15

    CH3

    I phase A

    CH4

    I g Q15

    => 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:

    CH1

     

    CH2

    S Q18

    CH3

    I phase B

    CH4

    I g Q18

    CH1

     

    CH2

    S Q15

    CH3

    I phase A

    CH4

    I g Q15

    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:

    CH1

     

    CH2

    S Q18

    CH3

    I phase B

    CH4

    I g Q18

    CH1

     

    CH2

    S Q15

    CH3

    I phase A

    CH4

    I g Q15

    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:

    Q1Why 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. 

    Q3What 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):

    CH1

    Vm (Pin 4)

    CH2

    VDS Q

    CH3

    FAULTn

    CH4

     

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

    CH1

    Vm (Pin 4)

    CH2

    VDS Q

    CH3

    FAULTn

    CH4

     

    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

     

    board serial number

    error

    axis

    rt AOUT1
    (ns)

    ft AOUT1
    (ns)

    rt AOUT2
    (ns)

    ft AOUT2
    (ns)

    rt BOUT1
    (ns)

    ft BOUT1
    (ns)

    rt BOUT2
    (ns)

    ft BOUT2
    (ns)

    633

    X AOCP + X BOCP + Z UVLO

    X

    180

    77

    275

    76

    168

    77

    280

    77

    633

    X AOCP + X BOCP + Z UVLO

    Y

    185

    80

    170

    78

    161

    80

    178

    80

     

    board serial number

    error

    axis

    rt AOUT1
    (ns)

    ft AOUT1
    (ns)

    rt AOUT2
    (ns)

    ft AOUT2
    (ns)

    rt BOUT1
    (ns)

    ft BOUT1
    (ns)

    rt BOUT2
    (ns)

    ft BOUT2
    (ns)

    633

    X AOCP after endurance

    X

    172

    75

    265

    75

    163

    75

    276

    79

    633

    X AOCP after endurance

    Y

    178

    75

    163

    72

    160

    78

    176

    78

     

    =>  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

     

    CH1

    A1HS

    CH2

    AOUT1

    CH3

    A1LS

    CH4

    I A phase

     

    CH1

    A1HS

    CH2

    AOUT1

    CH3

    A1LS

    CH4

    I A phase

     

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I A phase

     

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I A phase

     

    CH1

    B1HS

    CH2

    BOUT1

    CH3

    B1LS

    CH4

    I B phase

     

    CH1

    B1HS

    CH2

    BOUT1

    CH3

    B1LS

    CH4

    I B phase

     

    CH1

    B2HS

    CH2

    BOUT2

    CH3

    B2LS

    CH4

    I B phase

     

    CH1

    B2HS

    CH2

    BOUT2

    CH3

    B2LS

    CH4

    I B phase

    BR,
    Rémi

  • 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:

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I A phase

    Trigger

    FAULTn

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    VM (pin 4)

    M

    VM – AOUT2

    Trigger

    FAULTn

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

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    VM (pin 4)

    Trigger

    FAULTn

    => 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.

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    VCP

    CH4

    VM (pin 4)

    Trigger

    FAULTn

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

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

    CH1

    A2HS

    CH2

    AOUT2

    CH3

     

    CH4

     

    Trigger

    FAULTn

    Occurrence when FAULTn goes low:

    CH1

    A2HS

    CH2

    AOUT2

    CH3

     

    CH4

     

    Trigger

    FAULTn

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

    Occurrence just before FAULTn goes low:

    CH1

    A2HS

    CH2

    AOUT2

    CH3

     

    CH4

     

    Trigger

    FAULTn

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

     

    Adding A2HS gate current measurement:

    CH1

    A2HS

    CH2

    AOUT2

    CH3

     

    CH4

    I gate A2HS

    Trigger

    FAULTn

    Other phase with normal rise times to compare:

    CH1

    B1HS

    CH2

    BOUT1

    CH3

     

    CH4

    I gate B1HS

    Trigger

    FAULTn

    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

     

    board serial number

    error

    axis

    rt AOUT1
    (ns)

    ft AOUT1
    (ns)

    rt AOUT2
    (ns)

    ft AOUT2
    (ns)

    rt BOUT1
    (ns)

    ft BOUT1
    (ns)

    rt BOUT2
    (ns)

    ft BOUT2
    (ns)

    557

    X AOCP

    X

    175

    70

    269

    73

    163

    73

    188

    74

    557

    X AOCP

    Y

    182

    80

    155

    74

    165

    82

    177

    83

     

    All oscilloscope screenshots below with standard parameters.

     

    Driver outputs concerned by OCP error (X AOCP):

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I phase A

    Trigger

    FAULTn

    => FAULTn goes down at (b) cursor

    => gate voltage grows abnormally slowly

     

    Charge pump voltages measurement:

    CH1

    VM (pin 4)

    CH2

    CP2 (pin 2)

    CH3

    CP1 (pin 1)

    CH4

    I phase A

    Trigger

     

    VM=58V

    CP1 max=11.6V

    CP2 max=60.8V

    TCP=2.5µs => fCP=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:

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I phase A

    Trigger

     

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

     

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

    CH1

    A1HS

    CH2

    AOUT1

    CH3

    A1LS

    CH4

    I phase A

    Trigger

     

    => 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

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I phase A

    Trigger

     

     

    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

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I phase A

    Trigger

     

     

    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):

    Qty

    Reference

    Description

    Manufacturer

    Manufacturer Reference

    2

    C204,C205

    Capacitor aluminium electrolytic 100µF 63V 20%

    UNITED CHEMI-CON

    EMVH630ARA101MKE0S

    2

    C195,C196

    Capacitor ceramic COG/NPO 100pF 50V 5%

    2

    C176,C177

    Capacitor ceramic X7R 1uF 100V 10%

    KEMET

    C1210C105K1RACTU

    2

    C172,C174

    Capacitor ceramic X7R 10nF 100V 10%

    2

    C224,C225

    Capacitor ceramic X7R 1uF 16V 10%

    2

    C214,C215

    Capacitor ceramic X7R 100nF 100V 10%

    2

    C218,C220

    Capacitor ceramic X7R 100nF 16V 10%

    2

    C219,C221

    Capacitor ceramic X5R 1uF 6,3V 10%

    4

    C180,C181,C183,C184

    Capacitor ceramic COG/NPO 20pF 50V 5%

    2

    R332,R333

    Resistor 10k 1/10W 1%

    Uniohm
    (or equivalent)

    HP02WAF1002TCE
    (or equivalent)

    24

    R214,R215,R216,R217,R218,

    R219,R220,R221,R233,R234,

    R235,R236,R237,R238,R239,

    R240,R254,R255,R256,R257,

    R280,R281,R283,R284

    Resistor 0 Ohm 1/16W 5%

    4

    R265,R266,R267,R268

    Resistor 0,03 Ohm 3W 1%

    BOURNS

    CRA2512-FZ-R030ELF

    16

    Q19,Q20,Q21,Q22,Q23,Q24,

    Q25,Q26,Q32,Q33,Q34,Q35,

    Q36,Q37,Q38,Q39

    Transistor N-channel 60V mosfet

    NXP

    BUK7Y15-60EX

    2

    U53,U52

    IC Stepper motor controller

    TI

    DRV8711DCP

     

    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):

    CH1

    A2HS

    CH2

    AOUT2

    CH3

    A2LS

    CH4

    I phase A

    Trigger

     

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

     

    Other bridge with normal behavior:

    CH1

    A1HS

    CH2

    AOUT1

    CH3

    A1LS

    CH4

    I phase A

    Trigger

     

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

    BR,

    Rémi

  • Remi,

    Thank you for the information.

    As we discussed privately, I will close this thread for now and we will continue the discussion privately. Once we reach a conclusion, i will re-open this thread and post our findings so that others may benefit from our investigation.