MCSDK Using Case and Debug
Preface
The customer used MCSDK 5.4.8 to generate code for a Hall sensor, but when the motor had a load during startup, there was a magnetic excitation noise. However, there were no additions to the code, only a motor stop and restart. We used the DAC interface for easy debugging and ultimately identified algorithmic adjustments and hardware modifications needed to resolve this issue.
Issue
In this case, when starting up, there was a magnetic excitation noise. First, we confirmed how the phase currents exhibited abnormal waveform lengths. This case used a Hall sensor for feedback rather than sensorless control. We measured the Hall signal combination, and as shown in the figure below, it is evident that the Hall signal exhibited rapid oscillations, somewhat resembling HFI (High-Frequency Injection). However, in MCSDK 5.4.8, this feature was removed.
Debug Flow
Step 1:
Because it was uncertain whether the switching occurred in the wrong state, we first captured the motor control status to ensure it reached the ‘idle’ state before initiating motor start or stop.
Step 2:
After completing the first step and still encountering the issue, we proceeded to investigate the source of the abnormal signal step by step. However, as shown in the figure below, the abnormal part of Id appeared normal without injected noise. Additionally, it was observed that Iq had actual commands to drive the motor towards the target.
Step 3:
After confirming that it was a software-related issue, we proceeded to isolate whether the problem was occurring at the feedback end or the drive end. When using sensorless run, there were no startup issues, so our focus narrowed down to the Hall sensor feedback.
We made some adjustments and compared the differences between the public version and the customized version. When using the Hall sensor feedback from the public version, an error preventing startup occurred. To address this, we increased the filtering capacitance for the Hall sensor and further raised it, which resulted in a reduced frequency of the issue.
Software Solution
Here, after verification, it was found that MCSDK 5.4.8 does not switch to FOC after starting with six-step commutation. As a result, there is a blank region in the prediction phase, and any noise can cause it to mispredict and lead to oscillations.
So, here, I will start by asking the manufacturer about HALL_CalcElAngle in hall_speed_pos_fdbk.c. After that, in version 6.1.2, there were corrections made to this part. Therefore, I will incorporate the corrected portion.
__weak int16_t HALL_CalcElAngle(HALL_Handle_t *pHandle)
{
int16_t retValue;
#ifdef NULL_PTR_CHECK_HALL_SPD_POS_FDB
if (NULL == pHandle)
{
retValue = 0;
}
else
{
#endif
if (pHandle->_Super.hElSpeedDpp != HALL_MAX_PSEUDO_SPEED)
{
pHandle->IncrementElAngle += pHandle->_Super.hElSpeedDpp + pHandle->CompSpeed;
pHandle->PrevRotorFreq = pHandle->_Super.hElSpeedDpp;
if (pHandle->IncrementElAngle >= S16_60_PHASE_SHIFT)
{
pHandle->_Super.hElAngle += pHandle->_Super.hElSpeedDpp + pHandle->CompSpeed - (pHandle->IncrementElAngle - S16_60_PHASE_SHIFT) - 1;
pHandle->IncrementElAngle = S16_60_PHASE_SHIFT;
}
else if (pHandle->IncrementElAngle <= -S16_60_PHASE_SHIFT)
{
pHandle->_Super.hElAngle += pHandle->_Super.hElSpeedDpp + pHandle->CompSpeed - (pHandle->IncrementElAngle + S16_60_PHASE_SHIFT) + 1;
pHandle->IncrementElAngle = -S16_60_PHASE_SHIFT;
}
else
{
pHandle->MeasuredElAngle += pHandle->_Super.hElSpeedDpp;
pHandle->_Super.hElAngle += pHandle->_Super.hElSpeedDpp + pHandle->CompSpeed;
}
}
else
{
pHandle->_Super.hElAngle += pHandle->PrevRotorFreq;
}
retValue = pHandle->_Super.hElAngle;
#ifdef NULL_PTR_CHECK_HALL_SPD_POS_FDB
}
#endif
return (retValue);
}