ST Motor Pilot V6.4 Nominal Current is not following MC Workbench Project current rating

[fmariz]

Hello and good day. I am doing a project of running a motor using 6-Step with Hall Sensor.

I am facing an Overcurrent issue while using Motor Pilot V6.4 in 6-Step + Hall Sensor mode. In MC Workbench, the current limit is set to 15A but the Nominal Current is shown as 2.16A in the Motor Pilot GUI. No matter what I do in MC Workbench, the Nominal Current doesn't change and always shows as 2.16A. Consequently, I can't start the motor as it there is always Over Current fault as the motor needs more than 2.16 to start.

I know that it's not a limitation of my Power Board as it is rated at 20A.

In MC Workbench, it's clearly stated 15 Apk is set and is within specification of Power Board.

The strange this is, when I try FOC + Hall Sensor mode, this doesn't happen and the Motor Pilot GUI is showing the correct Nominal Current limit (15A) below. Somehow, this issue only happens in 6-Step + Hall Sensor mode.

May I know why this Nominal Current setting is different between FOC and 6-Step GUI?

Here are the details of the project:

• BLDC Motor rating: 15A
• Control Board: B-G473E-ZEST1S
• Adapter: X-NUCLEO-IHM09M2
• Power board: EVALSTDRIVE101
• Software: ST MC Workbench v.6.4 and Motor Pilot v6.40

Edit: Added more details

[Fabrice LOUBEYRE]

Hi fmariz, I suggest you first to check this post:

hall-sensor-not-working-on-6-4

From my point of view, the problem you raised is only a display issue.

The firmware does not retrieve the current information from the MCSDK Workbench, and it is not displayed on the Motor Pilot (the default value of 2.16 A is shown).

Best regards.

Fabrice

[fmariz]

Thanks for the reply @Fabrice LOUBEYRE 

In that case, I am trying to think why my 6-Step design is causing the Over Current fault.

I have limited my power supply to just 5A peak and there's no Over Current option is unsupported anyway with my setup: 6-Step + Hall.

Do you know how to solve this issue? I have attached my MCSDK Workbench project for your reference.

[Fabrice LOUBEYRE]

Hi Fmariz, can you confirm that you have considered the modifications in your code regarding the "placement electrical angle" parameter.

To properly set the placement electrical angle parameter, update your code with the following:

1. The two defines into drive_parameters.h

#define STEP_SHIFT (HALL_PHASE_SHIFT / 60) /*!< Number of steps (60 degrees) into the Placement electrical angle. */
#define PHASE_SHIFT_DEG (HALL_PHASE_SHIFT - (STEP_SHIFT * 60)) /*!< Number of degrees remaining after STEP_SHIFT. */

2. The corresponding HALL_PHASE_SHIFT value of your HALL sensor into  pmsm_motor_parameters.h

#define HALL_PHASE_SHIFT  238

3. Update the management of the STEP_SHIFT parameter at the end of the function HALL_TIMx_CC_IRQHandler embedded into the file hall_speed_pos_fdbk_sixstep.c

...
if (0U == pHandle->PhaseShift)
{
LL_TIM_DisableIT_CC2(pHandle->TIMx);
}
else
{
/* Set the remaining degrees after STEP_SHIFT set up into HALL_State2Step. */
/* Compute the counter value % to speed vs 60 degrees (step). */
uint32_t PhaseShiftTemp = ((pHandle->PhaseShift * hHighSpeedCapture) / 60U);
LL_TIM_OC_SetCompareCH2(pHandle->TIMx, PhaseShiftTemp);
LL_TIM_EnableIT_CC2(pHandle->TIMx);
}

You can also generate your project with the new MCSDK 6.4.1, which integrates the fix.

Best Regards.

Fabrice

[fmariz]

Hi @Fabrice LOUBEYRE. Thanks for the suggestion. I'll let you know once I've tried it.

[fmariz]

Hi @Fabrice LOUBEYRE. I have upgraded to MCSDK 6.4.1 and confirmed that the generated code matches the changes you suggested. However, I still get the same Over Current fault.

Do you have any other ideas that I can try?

[fmariz]

@Fabrice LOUBEYRE I've found out that the fault is actually from the Driver Protection fault from STDRIVE101's nFault pin, and not Over Current fault as indicated. I've confirmed this by manually shorting the nFault Test Point to GND.

There's a bug with the Motor Pilot software.

[Fabrice LOUBEYRE]

Hi @fmariz, thank you for your feedback. As described in the UM2781 - Getting started with the EVALSTDRIVE101 document:

https://www.st.com/resource/en/user_manual/um2781-getting-started-with-the-evalstdrive101-stmicroelectronics.pdf

In chapter 5.5 Fault monitoring, the protection nFAULT of the STDRIVE101 is triggered for overcurrent, VDS monitoring, UVLO, or overtemperature. In the current implementation of the 6-step firmware, the driver protection error is identified as an overcurrent error. However, you are correct; it should be mapped to the driver protection error, as is done for the FOC algorithm, for example. The issue is not located in the Motor Pilot but in the MCSDK firmware.

Best regards.

Fabrice

[fmariz]

@Fabrice LOUBEYRE I hope this will be fixed in the next release.

Yes, I am aware of the details of Driver Protection. Only if the Motor Pilot software had indicated the correct 'error' reading, I'd have made my job easier.

By the way, I managed to get my motor running by disabling Driver Protection but I am careful not to run it aggressively.

[Fabrice LOUBEYRE]

Hi, @fmariz , I invite you to read again the:

https://www.st.com/resource/en/user_manual/um2781-getting-started-with-the-evalstdrive101-stmicroelectronics.pdf

About the 5.1 Overcurrent comparator chapter: You will find information on how to set the current limitation for your application. The MCSD WB 6-step project with your board configuration sets only a driver protection. Consequently, the maximum current (for example, 20 Apk in your project) set in the MCSD WB is not the overcurrent value considered for overcurrent protection.

Generally, an overcurrent value is set above the maximum current of the motor to account for transition phases where the current may exceed the normal range. However, the maximum overcurrent must remain below the maximum value supported by the board.

If the driver protection indicates an overcurrent, check it using a current probe if you have one. Additionally, consider adjusting the speed PID to smooth the transition phases.

Regarding STM32 support, you may have noticed that the 6-step algorithm is not as complex as FOC algorithm. Consequently, it requires fewer MIPS and has a smaller memory footprint. Since MCSDK 6.3.2, efforts have been made to reduce the memory footprint, simplify the firmware architecture, and add new relevant features, such as on-the-fly updates. Currently, only six STM32 families, typically low-cost STM32 microcontrollers, support 6-step figures: STM32F0, STM32C0, STM32G0, STM32F4, STM32F3, and STM32G4. Two new STM32 families, STM32G5 and STM32C5, are expected to be supported in MCSDK 7.0 in the future.

Best regards.

Fabrice