TMS320F28027F: Motor chattering issue when motor RPM > 90% of max motor RPM

What signals do you show in the figure above? Can you post some waveforms of the motor phase current captured by the oscilloscope with a current probe?

And please check what's the value of the variables, "gMotorVars.Vs", "gMotorVars.OverModulation" and "gUserParams.maxVsMag_pu" when the motor run at high speed.

The signals above are measured on one of the high side gates. I have ordered a current probe so it will take me a day or two to show those captures.

Here are the values you asked for:
gMotorVars.Vs = 0
gMotorVars.OverModulation = 0.5
gUserParams.maxVsMag_pu = 0.5

I took a few more scope shots below that show a single phase with a 2kHz low pass filter on them. In the first two images I'm running off the sensorless algorithm for the motor angle. The first plot is a 1,000 RPM on a 24V supply where the control is good. The second plot is at 1,175 RPM and the motor is starting to lose control. The third plot is using the hall effect sensors only (no sensorless) and that is a plot right at the speed where the control is starting to go bad.

It appears to me, this isn't an issues with the sensorless algorithm since this problems shows up in both sensored and sensorless. Is it possible we have too much noise on our current sense lines and the motor control is cutting off due to an overcurrent condition? What other signals would be helpful to show, besides the phase current, which I will post once available.

You are right. In most cases, the issue could be from the current or voltage sensing signals or the gate driver of the hardware board. You might refer to the lab guide using lab01b and lab01c to verify the hardware.

The value of gMotorVars.Vs  shouldn't be equal to zero if the motor is running. Please check if the following code is in your project, if not, add them to check the value of the gMotorVars.Vs.

// read Vd and Vq vectors per units
gMotorVars.Vd = CTRL_getVd_out_pu(ctrlHandle);
gMotorVars.Vq = CTRL_getVq_out_pu(ctrlHandle);

// calculate vector Vs in per units
gMotorVars.Vs = _IQsqrt(_IQmpy(gMotorVars.Vd, gMotorVars.Vd) + _IQmpy(gMotorVars.Vq, gMotorVars.Vq));

I added the Vd, Vq, and Vs measurements to the code. I also got my current probe in and those captures are shown below. Instability starts at about 0.45 Vs so roughly 90% of the way to my MaxPU of 0.5. The first plot shows a good current and voltage waveform at around 1k RPM. The next two show plots at 1.15k RPM which clearly shows the motor misfiring.

gMotorVars.SpeedRef_krpm = 1.15
Vs = 0.4423158169
Vq = 0.4335480332
Vd = -0.0134024024

Any more ideas on where we can go from here in terms of troubleshooting?

Here are some better shots with loss of control. I tried to increase the dead-time to 400 ns and that didn't seem to have an impact. I don't think I'm getting shoot-thru.

Blue = current shunt on phase A
Green = output of DRV shunt amplifier running at gain of 20 on phase A
Yellow = gate of the low side FET on phase A

As you see in the plot, there is a large amount of current flowing through the low side during the anomaly. The first plot is zoomed out, and the second plot is zoomed in on the output of DRV shunt amplifier signal (green).

It seems like the current and voltage sensing signals are not good enough for a motor drive. Could you please try to use the lab01b and lab01c to verify your own board first? To check if the issue is from the sampling circuit or the gate drive.

I was able to successfully complete the lab01b and lab01c without control issues.

I was able to modify the graphing feature of lab01c to produce a graph of the phase A ADC. The signal looks pretty good to me. In lab01c, I'm able to get up to around 1.2k RPM which is near the max RPM for a PU of 0.5.

Is it possible since I'm using project5b for my other tests that even at a max PU of 0.5, I'm getting close to needing overmodulation? Is it possible the current reconstruction needed for overmodulation could be causing loss of control at higher speeds with a PU of 0.5 if it is not included in the firmware?

When I approach 1.2kRPM, the current amplitude starts to fall off quickly as the back EMF approaches the supply voltage (to be expected). Is it possible the loss of signal relative to the noise at higher RPM could also be the control loss root cause?

Did you meet the same issue on the TI  EVM kit? You might increase the dc bus voltage to see what happens when running the motor at the same speed?

When I increase the DC bus voltage, the instability goes away. Like the title of my post, the issue really only happens when above 90% of max motor RPM for a given DC bus voltage. I believe I should be able to accelerate the motor up to the max motor RPM for a given maxVsMag_pu.

I do not have any issues getting to 100% of max motor RPM using the DRV8353RS-EVM, even if I replace the stock 7 mOhm shunts with 1.5 mOhm ones. We are going to try to add some additional filtering to the current shunt before the amplifier and see if that helps. That being said, the current shunt as measured by the firmware seems to look pretty good per my previous post.

It seems like you have to implement over-modulation with current re-construct as lab10a or field weakening control as lab09 for running your motor to a high speed. The over-modulation with current re-construct require high-quality current sensing signals, you might set  "USER_MAX_VS_MAG_PU" to (0.576) first if you try to use the lab10a. And then you may implement field weakening control if the motor can't run-up to the speed you want.

We went ahead and implemented lab10a. We are still seeing similar issues when we get to the higher RPMs. When we start to get the instability we also tend to get a lot of gate drive fault errors on our DRV8353. This also about 50% of the time causes the part to fail with a permanent GDF (gate drive) fault coming from the part, which requires us to replace the IC.

We also went ahead and look a look at the angle_pu in realtime to see if that was potentially an issue. We see a little error here or there in the angle but it is seems to be mostly smooth.

We have tried quite a few things so far. Is there any chance we could get some support directly from an FAE at TI on this issue?

You might increase the dc bus voltage to run the motor at the same speed as you mentioned above, and see what happens.

Did you have any chance to run the motor on TI EVM kit?  Did you meet the same issue?

We have run the same firmware with minor tweaks to the user.h file. The EVM has no problem running the motor up to fully speed / duty cycle without failures. As we have said before, if we increase the bus voltage for a given RPM, the issue goes away, but we feel we should be able to achieve max RPM with a 0.5 max_pu without causing IC failures.

We tried a new tactic today, and ran the motor using only the torque control and turned off the speed controller. This now allows us to run at full RPM without instability or motor driver failure. That being said, once we set the USER_MAX_VS_MAG_PU above 0.57, we instantly get a GDF failure and it breaks the DRV8353 IC and requires replacement. Is there something unique to the DRV8353 which requires more gate drive power or some other hardware requirement when trying to go from sinusoidal commutation to trapezoidal commutation? We are now using lab10a to do our tests which should support overmodulation as well as current reconstruction.

It seems like you have to limit the USER_MAX_VS_MAG_PU or PWM duty since the current sensing is not quite good at your own board.

The over modulation and current reconstruction still require high-quality current sensing signals if the USER_MAX_VS_MAG_PU  is greater than 0.5, especially greater than 0.57.

Can you help us quantify “current sensing not good enough”? Is there a signal to noise ratio spec or any feedback on filtering we can pursue to achieve the results we are looking for?

We also find it concerning the failure mode results in immediate damage to the DRV8353. Our hope was that the GDF, VDS, and OCP protections might help to keep permanent damage from rendering the inverter useless in production if errant noise were to enter the system or other factors that could result motor instability were to occur. In the past, we’ve come to rely on the DRV series parts in our designs and found them to be quite robust. So far, we’ve not had this experience designing around the DRV8353.  

It's difficult to have a quantified standard. You might take a look at some textbooks about PCB layout design and analog signals deal conditioning circuit. Or ask some guys to help to check your schematic and PCB layout design of your board.

I would like to close this thread since it's not the issue from the C2000 controller or motor control algorithm codes. Please let me know if you have any further questions on the reference design code on motor control. 

I will go ahead and let you proceed with closing this thread and we will seek support via other channels. We have completed further comparisons with the EVM and are seeing very similar current feedback signals so I'm a little suspect that this is in fact the root-cause. That being said, it does not appear you have any more constructive feedback for us regarding this issue.

OK. The major impaction could be from the PCB layout design, especially on current and voltage signals deal conditioning circuit. It seems like the maximum/scale current is far greater than the TI EVM board.