Recently I have bought STEVAL-SPIN3202 board, I have a specific bldc motor which i want to drive. In 6step algorithm , I want to edit the sequence of commutation according to the hall sensor inputs

[SJosh.6]

Please let me know if the board automatically detects the sequence for excitation or do we need to edit in the firmware, if we need to edit it in the firmware in which section I need to edit the sequence in 6step library.

[Cristiana SCARAMEL]

Hello @SJosh.6​ and welcome to the ST Community.

The board doesn’t automatically detect the sequence.

If the sequence of commutation of the hall sensors is not standard, the firmware has to be edited in the function MC_SixStep_NEXT_step included in the 6Step_Lib.c file.

Hereafter I report the first lines of the function with few comments:

void MC_SixStep_NEXT_step(int32_t Reference)
{
/*!< acquisition of the status of the sensors*/
  H1 = HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_0);
  H2 = HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_1);
  H3 = HAL_GPIO_ReadPin(GPIOA,GPIO_PIN_2);    
  hallStatus = (H1 << 2) | (H2 << 1) | H3; 
 
/*!< Check of the flag control for motor alignment */
  if(SIXSTEP_parameters.ALIGN_OK != FALSE) 
  {
 
/*!< Check for motor spinning direction */
    if(Reference > 0)
    {
      switch (hallStatus)
      {
        case 2:
        {
/*!< Hall sensor status decoding*/
          SIXSTEP_parameters.next_step_pos=1;
          HF_TIMx.Instance->CCR1 = SIXSTEP_parameters.pulse_value;
          HF_TIMx.Instance->CCER = TIM_CCER_CC1E | TIM_CCER_CC1NE | TIM_CCER_CC2E | TIM_CCER_CC2NE;
        }
        break;

Morever, note that he STEVAL-SPIN3202 evaluation board supports the digital Hall sensors as motor position feedback with some hardware changes.

The sensors can be connected to the STSPIN32F0A by closing jumpers JP5, JP6 and JP7 (open by default) and opening JP9, JP10 and JP11 (used for BEMF sensing mode).

Let me know if these info are useful to you, if yes please "Select as Best" button to close the topic.

[SJosh.6]

Hello @Cristiana SCARAMEL​ , Thank you so much for your response. So do we need to change Halls status value i.e "case x" or we need to change the value of "SIXSTEP_parameters.next_step_pos=x", its quite confusing for me , I am a entry level developer, please help me with it , for the reference i will attach the commutation table of my motor, please go through it , and help me to solve the issue.

[Cristiana SCARAMEL]

Hi @SJosh.6​,

The best and easier way is to change the “case x�? according with your table AND check that spinning direction is the expected one.

Moreover, since the firmware updates the timer registers based on the expected values previously set, I would also suggest to explicit all the capture compare values for the three phases adding the missing ones.

For instance:

case 2:

{

        SIXSTEP_parameters.next_step_pos=1;

HF_TIMx.Instance->CCR1 = SIXSTEP_parameters.pulse_value;

HF_TIMx.Instance->CCR2 = 0;

HF_TIMx.Instance->CCR3 = 0;

HF_TIMx.Instance->CCER = TIM_CCER_CC1E | TIM_CCER_CC1NE | TIM_CCER_CC2E | TIM_CCER_CC2NE;

}

Break;

Considering your table, one can observe that it corresponds with the firmware table with the following match:

• A= half bridge phase U (channel 1)
• B= half bridge phase V (channel 2)
• C= half bridge phase W (channel 3)
• HS1=hall sensor corresponding to H3
• HS2=hall sensor corresponding to H2
• HS3=hall sensor corresponding to H1

and

• reference < 0

Doing so, the first configuration of the table (HS1 =1) would be H3=1 -> case 1 of reference < 0 -> W active and switching (CCR3=pulse_value and CCER= TIM_CCER_CC3E | TIM_CCER_CC3NE) and V active (CCR2=0 and CCER= TIM_CCER_CC2E | TIM_CCER_CC2NE) that corresponds to your table CH=1 and AL=1.

In conclusion, if the table is specified for counterclockwise direction, with the motor connected as above, the firmware should properly work.

If it doesn’t you just need to replace the condition Reference > 0 with Reference < 0.

Let me know if I solved your doubts.

[SJosh.6]

Hey @Cristiana SCARAMEL​ , thank you so much for the response, I need a clarification in the above solution, so in "Doing so, the first configuration of the table (HS1 =1) would be H3=1 -> case 1 of reference < 0 -> W active and switching (CCR3=pulse_value and CCER= TIM_CCER_CC3E | TIM_CCER_CC3NE) and V active (CCR2=0 and CCER= TIM_CCER_CC2E | TIM_CCER_CC2NE) that corresponds to your table CH=1 and AL=1.", since the condition is CH=1 and AL=1, do we need to activate W and V or W and U, cause A->U,B->V,C->W. Please clarify the confusion.

[Cristiana SCARAMEL]

Hello @SJosh.6​,

I double-checked firmware and provided decoding table.

 

Considering that the commutation table refers to CCW rotation, that is the one implemented in the firmware, corresponding to the standard motor configuration in the picture where A, B and C are U, V and W phases respectively.

So, if connections are OK, nothing should be changed.

Otherwise, in case the commutation is supposed to be in the opposite direction, you only need to replace if(Reference > 0) with if(Reference < 0).

Let me know if these info help you in your project.

[SJosh.6]

Hey @Cristiana SCARAMEL​ , the previous solution which you had gave me worked at some extent, like the motor could complete one spin (with a small **** or it may have skipped one step)and stopped due to the error, but according to the recent solution the motor is not even spinning its just stalling. Please do let me know what to do in this situation, it is very important for me to run this motor with the help of STEVAL board,

[Cristiana SCARAMEL]

Hi @SJosh.6​,

Have you tried changing the Reference parameter to change the direction?

Moreover please recheck all the connections and the communication, it’s really weird that the motor doesn’t move.

[SJosh.6]

Hi @Cristiana SCARAMEL​ . I have attached some of the photos of the eval board and motor connections, please do check it . As far as I know , the connections are good , the only problem I am facing is in firmware, because your previous solution i.e"Changing of case x:", helped me to atleast run the motor with some lag in startup state but at run state it gives an error and stops the motor to run. Please see through my queries and provide me the solution. Thank You.

[Cristiana SCARAMEL]

Hi @SJosh.6​,

your hardware connections look ok.

The previous change of the “case x�? wasn’t right. With Hall sensors the firmware may be able to spin the motor even if not properly driven but inefficiently.

Please try reversing the direction definition in the firmware by changing:

if(Reference > 0)
   {
     switch (hallStatus)
….

with

if(Reference < 0)
   {
     switch (hallStatus)
….

Let me know if you are able to solve the issue.