DRV8301-69M-KIT: Current control and zero commanded current motor hum

That's normal for enabling current PID to control the reference Id and Iq to zero. You can add a flag to disable PWM output when you set Iq_ref to zero, but you need to clear the integral (Ui) before you enable PWM output again. Or you can use a small Kp and Ki when setting Id_ref to Zero, the motor vibration will be very slight also.

Yea, I did think of doing it that way and remembered that the integrator will probably keep acculumating error one way or the other, so I should zero it before enabling the PWMs or the accumulated Ui would do something drastic before wounding down.

What would happen if I set the Kp and Ki to zero, then disabled the PWMs while IqRef is zero. And then returning them to their normal values and and enabling PWMs when a current is commanded again? They shouldn't accumulate error if their gains are zero.

I also want the system to complete freewheel while commanded current is zero and I think that the best way to do it is with disabling the PWMs.

You can't disable PWM output, set Kp and Ki to Zero in the same time which keep Ui with a fixed value. You only need to use one of the following two ways.
1. Disable PWM, clear Ui before set Iq_ref and re-enable PWM.
2. Keep enabling PWM, and set a small Kp and Ki when Iq_ref is Zero.

So going with the 2nd way you proposed. When the iq_ref is zero, could I just divide the kp and ki with a 100 for example and then multiply them by a 100 once current is commanded again?

Sorry for bumping this old thread, but the Iq current controllers Ui can be zeroed with "PID_setUi(obj->pidHandle_Iq,_IQ(0.0));" ??

You are right. You can use PID_setUi(obj->pidHandle_Iq,_IQ(0.0)) to set Ui of Iq PI to zero, and it's better to set all pwm outputs to zero during Iq_ref equals to zero and motor stops.
gPwmData.Tabc.value[0] = _IQ(0.0);
gPwmData.Tabc.value[1] = _IQ(0.0);
gPwmData.Tabc.value[2] = _IQ(0.0);

I now have a working implementation. Thanks for the help

if(gMotorVars.IqRef_A <= _IQ(0.4) && gMotorVars.IqRef_A >= _IQ(-0.4) && gMotorVars.Flag_Run_Identify == true){
            if(freeWheeling == false){
                HAL_disablePwm(halHandle);
                gPwmData.Tabc.value[0] = _IQ(0.0);
                gPwmData.Tabc.value[1] = _IQ(0.0);
                gPwmData.Tabc.value[2] = _IQ(0.0);
                freeWheeling = true;

                gMotorVars.IqRef_A = 0;
                updateIqRef(ctrlHandle);
            }
        }
        else if(gMotorVars.Flag_Run_Identify == true){
            if(freeWheeling == true){
                PID_setUi(obj->pidHandle_Iq,_IQ(0.0));

                HAL_enablePwm(halHandle);
                freeWheeling = false;
            }

            //update Iq reference
            updateIqRef(ctrlHandle);      //for current control
        }

The problem still persists. The PID controllers are still running in the background and the problem appears when I have first commanded some current for the motor, then zero the commanded current and then command current again. I see that my Vq and Vd values are still running and after a while my Vs saturates to my max overmodulation of 0.5774 and if I then command some current again and activate the PWM outputs, the motor of course jerks a bit and the MCU resets(Flag_enableSys and Flag_Run_Identify reset to zero). If I zero the commanded current after commanding some first (PID gains get initialized?) and then quickly command some again the Vs doesn't have time to saturate to the max and the jerk is much less violent and it doesn't reset the Flags previously mentioned.

By the way, does the motor parameter USER_MOTOR_MAX_CURRENT do anything in current control mode or is it only for the speed PI controller's output?

Another question, when the Vs has saturated to the overmodulation value and I re-enable the PWMs by commanding current and the motor jerks and the MCU seems to reset, or at least the Flag_enableSys and Flag_Run_Identify reset. Does it happen via the TripZone-input connected to the DRV8301 or is it MCU firmware or actual voltage spike that

EDIT: I traced the flags resetting to be caused by very noisy 3v3 supply, which dipped enough to reset the MCU and therefore caused all the variables to reset.