Hall sensor feedback control noise attached load during startup on MCSDK5.4.8

[YJHUNG]

When using MCSDK 5.4.8 to generate code with Hall sensor feedback control and considering the possibility of an attached load during startup, there is a chance of encountering excitation noise.

Normally, the U-phase current signal should correspond to the rising edge of the U-phase Hall sensor.

However, under abnormal conditions, there are multiple U-phase current signals between the rising and falling edges of the U-phase Hall sensor, resulting in the generation of motor excitation noise.(Follow ST file adjustments to the Hall phase section, which have already  fine-tuned for optimal performance.)

 I'm currently using the command MC_ProgramSpeedRampMotor1 to set the motor startup parameters, and the issue persists when switching between MC_StopMotor1 and MC_StartMotor1 after the first startup attempt.
Attempts to use MC_Clear_IqdrefMotor1/MC_AcknowledgeFaultMotor1 to clear the buffer when stopping the motor have been ineffective.

Assistance is required to identify which specific component needs adjustment to resolve this issue.

[Gael A]

Hello YJHUNG,

I have a few questions to help me understand what you are experiencing :

May I ask you what is the configuration that you are using ? Is it a custom board ? On which MCU are you working ?
Could you tell me what kind of motor you are using please ?
What are the abnormal start-up conditions you are referring to ? Is it repeatable and characterizable ?
Are you waiting for the motor to stop completely before initializing another start-up, or do you call MC_StartMotor1 directly after ?

Thank you,
Gaël A.

[YJHUNG]

We are currently referencing the combination of Nucleo-G431 and X-NUCLEO-IHM08M1 to adapt the configuration onto our custom-designed board. The main difference in configuration between the two lies in the MOS and driver, which have been modified to handle higher current.

The motor being used is the M155CN drum motor with a pole pair count of 10P. The design operates at 36V with an average power of 250W.

The observed abnormal phenomenon involves a high-frequency signal in the U-phase during the startup phase, leading to a audible magnetic noise from the motor. This phenomenon occurs around 70% of the time, specifically during startup with a load. Startup without a load is normal.

We have attempted to address this issue by waiting for the motor to return to an idle state before executing the next action. The occurrence of this issue is closely tied to the motor being near stoppage, and we have also observed the same event during stop-and-start sequences.

The specific description of the anomaly is that the U-phase current experiences high-frequency oscillations during startup when there is either no Hall signal or within a single Hall signal cycle.

Under normal conditions, a U-phase current aligns with the Hall signal. Currently, direct use of the development board results in a high probability of encountering a 'speed feedback error.' As a result, we have made modifications to the configuration of the Hall signal input into the TIM terminal, as shown in the diagram

[Gael A]

Hello YJHUNG,

Thank you for your answer. I will try to replicate your setup and see what can be the issue you are facing. In the meantime, could you tell me if you are sensing current with 3-Shunt or a single shunt ?

Regards,
Gaël A.

[YJHUNG]

I used 3-shunt 

[YJHUNG]

An update on the current status: I generated a new code using version 6.1.2 to compare and update HALL_Init_Electrical_Angle / HALL_CalcAvrgMecSpeedUnit to the original version 5.4.8. This has resulted in an improvement in the frequency of occurrences, with a significant reduction in the frequency. However, there is still a chance of it happening intermittently. I have also conducted a comparison by measuring three Hall signals against the occurrence. It appears that the issue occurs when the magnetic excitation takes place before the Hall signals are generated. This seems to be related to the positioning angle. Is there a corresponding solution or reference article available for this particular issue?

Red: U-phase current

[Gael A · Accepted solution]

Hello YJHUNG,

The issue you are facing now reminds me of one that will be solved in the next release.
Please try replacing the HALL_CalcElAngle in hall_speed_pos_fdbk.c by this new one :

__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);

}

You also need to add a few lines in HALL_TIMx_CC_IRQHandler

    /* Reset incremental value */

    pHandle->IncrementElAngle = pHandle->_Super.hElAngle - pHandle->MeasuredElAngle;

This goes between the MTPA check and the first capture discard in HALL_TIMx_CC_IRQHandler

 and HALL_Init_Electrical_Angle :

    /* Reset incremental value */

    pHandle->IncrementElAngle = 0;

 This one goes at the end of HALL_Init_Electrical_Angle, just before /* Initialize the measured angle */

Of course, you also need to add the IncrementElAngle to the HALL_Handle_t struct in hall_speed_pos_fdbk.h :

  int16_t IncrementElAngle;/*!< This is the cumulated electrical angle between

                               two consecutive Hall sensor commutations.*/

The purpose of this fix is to prevent the algorithm to calculate an angle farther than the next HALL position before the HALL returns a sector change. This may be what you are facing : the FW may compute a speed that is greater than it actually is because of the load, and then get a wrong estimation of your motor positioning. When the HALL sensor then returns the new value, there is a big mismatch between the calculated value and the measured value, which may cause current instability.

Hope this will help,
Gaël

[YJHUNG]

Currently, I've implemented two things based on your suggestions: adding code and increasing the filtering capacitor for HALL signals. So far, the issue hasn't occurred in testing. Additionally, I noticed the Hall MTPA function. Does enabling this function bypass the initial estimated angle from the Hall sensors?

[UltiFix]

Hello,

@Gael A 

I read through release notes for 6.2, 6.2.1, and 6.3 and do not see this fix called out. Can you confirm if it was/was not included in any of these releases?

Can you also explain if disabling MTPA will also resolve this issue?