DRV10983: HWiLimitThr setting has inconsistent results

Hey Mark,

If I understand you correctly, it sounds like you're experiencing the Current Limit Lock0 at various levels that do not correspond with the HWiLimitThr.

One explaination for this is that current limit is monitored on all 3 phases. I assume you are only monitoring current on one of the three phases which does not provide information about what the level the current is being triggered. It is entirely possible to have low current on one phase while the current flowing through the other 2 are high. If you have 3 current probes, that will give the full story. Otherwise, try experimenting by monitoring each of the 3 phases a handful times (assuming the current limit lock is easily replicable) and this may or may not help answer the question.

Another piece of information that is helpful is when you are experiencing Current Limit. Is this during Open Loop or Closed Loop operation? Note some other current limits come into play when accounting for open loop or closed loop. Providing your EEPROM settings (preferably using the GUI) can help us understand the bigger picture a bit better.

Best,

-Cole

So I had a similar thought about the phase currents being different.  I only have one current probe, but the fault is so easy to reproduce that I captured the current when the fault occurred multiple times on each phase.  I would imagine statistically speaking that there is a chance the current fault is always on a different phase than I'm measuring, but with a star wound motor, I would think that I would have seen an anomaly at some point in my testing or at least see a current closer to the 2.4-3.2A thresholds that are programmed in, when I have never witnessed anything higher than 1.49A peak on any phase.

All these errors are occurring while the DRV10983 is running closed loop, I can easily see on the scope when the closed loop functionality takes over.

I already have a bit of framework built around the DRV10983 in code, so it is initialized via a struct in code for portability.  Most settings are configured using enums which should be pretty easy to determine the value.  The initialization code writes the registers out with proper bit shifting and masking from the enums:

/// DRV10983 configuration.
static const drv10983_device_config_t DRV10983_DEVICE_CONFIG =
{
.doubleFreq = drv10983_motor_param_DoubleFreq_25kHz,
.Rm = 0x5B, // 3.4 ohm
.AdjMode = drv10983_motor_param_AdjMode_FullCycle,
.Kt = 0x3A, // 73.3 mV/Hz
.CtrlAdvMode = drv10983_motor_param_CtrlAdvMode_FixedTime,
.Tdelay = 0x4C, // 480us
.ISDThr = drv10983_sys_opt_ISDThr_6Hz,
.IPDAdvAgl = drv10983_sys_opt_IPDAdvAgl_30d,
.ISDen = drv10983_sys_opt_ISDen_disable,
.RvsDrEn = drv10983_sys_opt_RvsDrEn_disable,
.RvsDrThr = drv10983_sys_opt_RvsDrThr_6P3Hz,
.OpenLCurr = drv10983_sys_opt_OpenLCurr_0P4A,
.OpLCurrRt = drv10983_sys_opt_OpLCurrRt_0P7VCCps,
.BrkDoneThr = drv10983_sys_opt_BrkDoneThr_disable,
.CtrlCoef = drv10983_sys_opt_CtrlCoef_1,
.StAccel2 = drv10983_sys_opt_StAccel2_14Hzps2,
.StAccel = drv10983_sys_opt_StAccel_38Hzps,
.Op2ClsThr = 0x11, // 25.6Hz
.AlignTime = drv10983_sys_opt_AlignTime_0P33s,
.FaultEn3 = drv10983_sys_opt_FaultEn3_enable,
.LockEn2 = drv10983_sys_opt_LockEn2_disable, // TODO - Enable LockEn2 - Abnormal Kt
.LockEn1 = drv10983_sys_opt_LockEn1_enable,
.LockEn0 = drv10983_sys_opt_LockEn0_enable,
.AVSIndEn = drv10983_sys_opt_AVSIndEn_disable, // TODO - Enable Inductive AVS
.AVSMEn = drv10983_sys_opt_AVSMEn_enable,
.AVSMMd = drv10983_sys_opt_AVSMMd_AVS_TO_VCC,
.IPDRlsMd = drv10983_sys_opt_IPDRlsMd_Brake_Release,
.SWiLimitThr = 0x0A, // 2A // TODO - Look into limiting the accleration current
// .HWiLimitThr = 0x04, // 2A
// .HWiLimitThr = 0x06, // 2.8A // TODO - If we lower the acceleration current, possibly lower the lock current limit
.HWiLimitThr = 0x05, // 2.8A // TODO - If we lower the acceleration current, possibly lower the lock current limit
.LockEn5 = drv10983_sys_opt_LockEn5_enable,
.ClsLpAccel = drv10983_sys_opt_ClsLpAccel_0P77VCCps,
.Deadtime = 0x09, // 400ns // TODO - Potentially increase deadtime
.IPDCurrThr = 0, // IPD Disabled
.LockEn4 = drv10983_sys_opt_LockEn4_enable,
.VregSel = drv10983_sys_opt_VregSel_5V,
.IPDClk = drv10983_sys_opt_IPDClk_24Hz,
.FGOLse = drv10983_sys_opt_FGOLse_Op_and_Cl,
.FGcycle = drv10983_sys_opt_FGcycle_1_pulse_per_1_cycle,
.KtLckThr = drv10983_sys_opt_KtLckThr_Hi_2Kt_Lo_1d2Kt,
.SpdCtrlMd = drv10983_sys_opt_SpdCtrlMd_PWM,
.CLoopDis = drv10983_sys_opt_CLoopDis_disable,
.MaxSpd = 405,
.MinSpd = 60
};

Note the MaxSpd and MinSpd are not register values, they are the maximum and minimum value for the SpdCtrl registers that I determined through testing for this project in order to limit the range of operation.

One other interesting note that I didn't initially mention is that I have been running my test setup without any fault conditions for well over a month, but only recently started seeing the fault condition.  The change that brought this out is the PI speed control loop.  Previously, the code simply wrote a single value out to the SpdCtrl registers based on a button press that would cycle through 6 different speeds, but SpdCtrl was only written once per button press, and the actual speed of the motor was not taken into account.  In order to clean up variations in speed over operating conditions, I wrote a simple PI speed control loop which reads back the motor speed over I2C, runs the PI loop, and then writes a new value out to SpdCtrl every 10ms.  I wrote a quick data logger that polls the last measured speed, target speed, PI error, PI intergral, and output SpdCtrl value to see if there is any large swings in the SpdCtrl value that could be triggering the error, but when the errors occur, only very small changes are being made to the SpdCtrl.  I also validated this using a logic analyzer looking at the I2C activity before and after the Lock0 fault occurs.

So I guess what I'm curious of is: Is there a maximum frequency that you can write out SpdCtrl updates?  There is a possibility that I am updating the SpdCtrl register more than once between phase zero crosses since my PI loop is fixed frequency, could this cause a problem?  When not writing out SpdCtrl updates periodically, I don't seem to have the issue, so it seems like this could be related to the SpdCtrl write speed.

Let me know if you have any other questions I could answer to help out,

Mark