Wrong 6-step commutation from Hall sensors not 60° aligned since v6.4.0

jovijuan · ‎2025-09-17

I have a custom board with a STM32G491 with a single-shunt driver for 6-step with hall effect sensors.

One of the motors I have has a hall sensor placement close to 120°. I followed the process described in documentation (section 3. "Setting up the system when using Hall-effect sensors" in "Hall sensor feedback processing" page) and the Hall delay, described as "the delay in electrical degrees between the maximum of the B-emf induced on phase A and the first rising edge of signal H1" was approximately 108°.

I used that value with v6.3.2 and I confirmed that current through motor phases was cleaner with 108° than with 120° (with both values rotating correctly)

When v6.4.0 came out I tried the same configuration. The motor only vibrated violently with either 120° or 108° for hall delay. I reported it in this forum and a code modification was suggested that eventually was included in v6.4.1. But that solution only fixed when Hall delay is aligned with 60° steps.

With v6.4.1:

If I set 120° (it results, in the code, in a STEP_SHIFT of 2 and PHASE_SHIFT_DEG of 0) the motor rotates ok.
If I set 108° (it results, in the code, in a STEP_SHIFT of 1 and PHASE_SHIFT_DEG of 48) the motor vibrates violently again.
If I set 130° (it results, in the code, in a STEP_SHIFT of 2 and PHASE_SHIFT_DEG of 10), the motor rotates ok, but I don't know if the delay is ok. Same happens with other values above 120.

There seems to be an issue with the way that STEP_SHIFT and PHASE_SHIFT_DEG are used.

If I understood hall sensor delay definition correctly, in a motor where hall delay is 130° instead of 120°, the step commutation should have been advanced 10 electrical degrees in forward direction and delayed 10 electrical degrees in backwards direction versus the 120° version, but in both of them it seems delayed.
I added a toggle to an output pin during the CC2 ISR handling (used when PHASE_SHIFT_DEG is not 0 to call SixStep_StepCommution()) and captured hall signals and that pin signal both in forward and backward:

Forward:

Backward:

In both directions the toggles are always approximately 10 electrical degrees from hall changes, but delayed in both cases.

I also confirmed that, instead of STEP_SHIFT = 1 and PHASE_SHIFT_DEG = 50, I manually set STEP_SHIFT = 3 and PHASE_SHIFT_DEG = 50, the motor rotates in forward direction with no vibration, with commutation 10 degrees below the commutation it would show with 120 (STEP_SHIFT = 2 and PHASE_SHIFT_DEG = 0)

This is why I think that the logic for the conversion from hall status to steps and that sets commutation and sets CC2 ISR is wrong, but I have not figured out how to fix it.

VictorChiou · ‎2025-09-18

I have a similar problem.
Sadly, I didn’t get any reply from the official side after I reported it.

https://community.st.com/t5/stm32-mcus-motor-control/open-loop-control-in-mcsdk-6-4-1-cw-and-ccw-have-huge-difference/td-p/837018

Fabrice LOUBEYRE · ‎2025-09-26

Hi @jovijuan, first, I apologize for the delay.

First, I remind you that:

The Hall sensor placement, which refers to the electrical angle shift between each position of the Hall sensor with two possible configurations (60 or 120 electrical degrees), and the phase shift, which is the electrical angle shift between the H1 Hall sensor and the actual 0-degree electrical angle, are static.

Do you use different types of motors or only one motor while trying different phase shift values (120, 108, 130) because the actual value is unknown?

We do not have a motor with, for example, a phase shift value of 108 degrees. Can you provide us with the reference of your motor, please?

I am concerned that the MCSDK firmware supports only motors with a phase shift value equal to (modulo 60) + [0..30] degrees.

Below, you will find an updated version of the Hall management for MCSDK 6.4.1, which I hope will resolve your issue.

Please feel free to test it and provide your feedback.

Best regards

Fabrice

STuser2 · ‎2025-09-26

@Fabrice LOUBEYRE wrote:
I am concerned that the MCSDK firmware supports only motors with a phase shift value equal to (modulo 60) + [0..30] degrees.

Could you please confirm if it is only for 6 step communication or FOC as well? For one of my motor the phase shift value is 300.

jovijuan · ‎2025-09-26

Thanks for your answer, Fabrice,

The motor I'm using, according to the datasheet, uses a 120 degrees configuration with a phase shift of 120 degrees. And that is the configuration I used to initial testing. But phase current waveform showed something weird at one side of the hall sensor steps. Then I plotted motor phases and hall sensor signals while manually rotated the motor and realized that the placement of the hall-effect sensors in the specific motor I had in my hands, had a phase shift close to 108 or 110 degrees.

This is the plot for FORWARD:

and this is the plot for BACKWARD:

CH1: Hall1
CH2: Phase U
CH3: Phase V
CH4 Phase W

This is due to a bad manufacturing tolerance in the hall-effect sensor placement inside the motor.

I have added the plots because they illustrate that the same phase shift offset needs a delay in one motor direction and an advanced commutation in the other.

Using v6.3.2 (that seems to behave correctly with any phase shift) and 108 degrees as phase shift, the phase current waveforms were closer to the expected ones.

When I used 130 degrees it was only to diagnose the error in the hall sensor management.

What I have in mind for the modification that would accept any shift would be:

STEP_SHIFT gets the value of the closest mod_60 step and that PHASE_SHIFT_DEG had a value in the range (-30, +30):
If possitive and forward (or negative and backward) the commutation is just delayed those degrees with CC2, as it's now.
If negative and forward (or positive and backward) a correction would be needed for the step (add one in the movement direction) and the delay with CC2 would be 60-|hall_delay|.

I have still not tested your code but I will.

Regards,

Luis

jovijuan · ‎2025-09-30

Hi again, Fabrice,

I've tried to test the modification you sent, but it doesn't compile: on line 204 of mc_tasks_sixstep.c:

if (SDC_GetOpenLoopFlag(pOLS[M1]))

neither SDC_GetOpenLoopFlag or pOLS are defined.

I've been working on the modification I suggested before:

I redefined STEP_SHIFT in drive_parameters.h:

#define STEP_SHIFT                         ((HALL_PHASE_SHIFT + 30) / 60)

keeping unchanged the definition of PHASE_SHIFT_DEG, but now it ranges from -30 to +29

In hall_speed_pos_fdbk_sixstep.h, the definition of PhaseShift changes from uint32_t to int32_t
At the very end of HALL_State2Step function in hall_speed_pos_fdbk_sixstep.c I add or substract a step for the shift combinations that need and advanced commutation instead of a delay:

  if ((pHandle->Direction == POSITIVE) && (pHandle->PhaseShift > 0)) {
    /* Add one step to stay in the following step until CC2 event */
    pHandle->Step += 1U;
    if (pHandle->Step >= 6U) {
      pHandle->Step -= 6U;
    }
  }

  if ((pHandle->Direction == NEGATIVE) && (pHandle->PhaseShift < 0)) {
    /* Subtract one to stay in the previous step until CC2 event */
    pHandle->Step += 5U;
    if (pHandle->Step >= 6U) {
      pHandle->Step -= 6U;
    }
  }

At the end of HALL_TIMx_CC_IRQHandler function inside hall_speed_pos_fdbk_sixstep.c, the definition of PhaseShiftTemp

uint32_t PhaseShiftTemp = ((pHandle->PhaseShift * hHighSpeedCapture) / 60U);

Is replaced by:

      uint32_t PhaseShiftTemp;
      if (pHandle->Direction == POSITIVE) {
        if (pHandle->PhaseShift < 0) {
          PhaseShiftTemp = ((-pHandle->PhaseShift * hHighSpeedCapture) / 60U);
        } else {
          PhaseShiftTemp = (((60U - pHandle->PhaseShift) * hHighSpeedCapture) / 60U);
        }
      } else {
        if (pHandle->PhaseShift < 0) {
          PhaseShiftTemp = (((60U + pHandle->PhaseShift) * hHighSpeedCapture) / 60U);
        } else {
          PhaseShiftTemp = ((pHandle->PhaseShift * hHighSpeedCapture) / 60U);
        }
      }

I've tested it with multiple values of the shift and the behavior is the expected with either positive or negative values of PHASE_SHIFT_DEG in both forward and backward.

It can be tested with any motor, adding or removing 20 degrees from the nominal HALL_PHASE_SHIFT distorts the current waveform but the motor should rotate correctly.

Diff file with the modifications is attached.

Regards,

Luis