• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 87 subscribers
  • Views 539 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TMS320F28027F: Lab10A: Damaged inverter while overmodulating

TMS320F28069M: Damage to DRV Gate Driver During Over-modulation

James McKenna
Prodigy 136 points
Part Number: TMS320F28069M
Other Parts Discussed in Thread: DRV8353

We are using a custom board with a TMS320F28069M, a DRV8353RSRGZR, and 3 low side 750uA current shunts. We have had very few issues with the DRV but now when we attempt to over-modulate there is almost immediately a permanent fault with hardware damage, even when USER_MAX_VS_MAG_PU was as low as 0.51. We used the Lab10a code with the IDRIVE and user.h settings which were working fine for USER_MAX_VS_MAG_PU = 0.5. The resulting SPI fault is VGS on one of the low side gate drivers of the DRV chip. To me this indicates that a shoot through problem is occurring. None of our FETs have failed, it is always the DRV chip.

The things we are thinking of trying are:

  • Use the longest hardware dead time on the DRV SPI
  • Adding software dead time in the PWM generator of the F28069
  • Reducing the IDRIVE current to the lowest settings.

Does anyone have any other advice on how can we protect our DRV from damage?

Additionally, we have dual FETs and a 0 Ohm gate resistor, so we have the option of putting a resistor between the gate and the FETs.

  • 0
    Guru 56033 points

    Hi James,

    I think you can rule out any shoot through since the NFETS drain to source junctions were not shorted. You might want to post this issue in the power driver forum see what they think. Though it's more likely you need to add a gate resistor of some value other than 0R since gate current setting may be stressing the HO/LO outputs. The Toff current setting is typically made stronger than Ton to make the NFETS shut down faster as to stop shoot through.

    We don't see much info of gate driver shoot through occurring in the HO or LO Totem poles. 

  • 0
    TI__Mastermind 28220 points

    Hi James,

    One of our DRV8353 experts will get back to you shortly, thank you for your patience.

  • 0 in reply to Luke Jones
    TI__Guru** 116090 points

    You may set the right Vds of the DRV to protect the DRV and FET, and also you need to configure the right dead time and IDRIVE current according to the FET.

    Did you see any over current and over voltage on the motor phase and dc bus lines?

  • 0
    Prodigy 136 points

    Thank you both.

    So one potential issue we can see is that setting the USER_MAX_VS_MAG_PU in user.h doesn't actually change the runtime value for the lab. The value of MATH_TWO_OVER_THREE is hard coded and overwrites the user setting per the following two lines:

    gMotorVars.OverModulation = _IQ(MATH_TWO_OVER_THREE);
CTRL_setMaxVsMag_pu(ctrlHandle,gMotorVars.OverModulation);

    So we have actually been running at USER_MAX_VS_MAG_PU 0.66667 for previous trials when we thought it was lower.

    After running a few more experiments with USER_MAX_VS_MAG_PU=0.51 we can see that there are ADC current spikes that are successfully ignored. We are currently running more tests and want to eventually get to 100% duty cycle. We have some concerns with the sampling. Looking at the shunts which are being ignored in the ISR shows that there is almost an overlap in ignored shunts to where we will soon need to reconstruct two ADC samples at once.

    In svgen_current.h it looks like the code has been commented out which handles the ignore two shunts case? 

    /*
  else if (svgencurrent->IgnoreShunt==ignore_ab)
  {		// repair a and b based on c
    Ia = (-Ic)>>1;       //Ia = (-Ic)/2;
    Ib = Ia;              //Ib = Ia;
  }
  else if (svgencurrent->IgnoreShunt==ignore_ac)
  {		// repair a and c based on b
    Ia = (-Ib)>>1;       //Ia = (-Ib)/2;
    Ic = Ia;              //Ic = Ia;
  }
  else if (svgencurrent->IgnoreShunt==ignore_bc)
  {		// repair b and c based on a
    Ib = (-Ia)>>1;       //Ib = (-Ia)/2;
    Ic = Ib;              //Ic = Ib;
  }
*/

    Do we need to bring this code back in if we want to try higher USER_MAX_VS_MAG_PU values?

  • 0 in reply to James McKenna
    TI__Mastermind 24851 points

    Hey James,

     

    Reducing the IDrive and increasing the dead time is good step to take when you suspect a shoot through. A good way to select IDrive is to aim for a rise/fall time of VDS to be between 100-200 ns for a fast switching. But I would have expected to see some MOSFET damage if that were the case.

    In order to better understand the situation, I would suggest capturing the waveforms of GHX, GLX and motor phase current for all three of the phases.

     

    Best Regards,

    Akshay

  • 0 in reply to James McKenna
    TI__Mastermind 18981 points

    Hi James, 

    Closing this thread - please let us know if you need further assistance, and help mark the answer above as 'resolved' if it answered your question. Thanks!

    Best Regards, 
    Andrew 

  • +1
    Prodigy 136 points

    Thank you for your answers. We have had many more gate drivers damaged since this post.

    We are changing our design to use phase shunts instead of low side shunts. That should eliminate the need for a current reconstruction techniques at the expense of additional power dissipation across the resistor.

  • 0 in reply to James McKenna
    Prodigy 136 points

    I just want to mention that after switching to in-line current shunt sensing the over-modulation up to 100% PWM duty cycle works flawlessly. The drawback is that we need external current sense amplifiers instead of the DRV8353 integrated amplifiers. This does not require a current reconstruction algorithm.

  • 0 in reply to James McKenna
    TI__Mastermind 24851 points

    Glad to know that it worked out!

    Best,

    Akshay