Experiences and issues of X-CUBE-MCSDK motor control, STM boards, FOC vs Sensored and related

The STM approach to the motor is well thought through in my opinion. But making it well structured and well organized costs in terms of certain level of complexity. I suspect also that STM has to deal with 'troublemakers' such as myself - I mean those users who need their newest 'bleeding edge' products and then question the apparent mismatch between the levels of development between those... I intent this thread to be a discussion-reports-question-answers for this development path of the motor control: X-CUBE-MCSDK + Nucleo or other MCU control boards + FOC sensorless vs sensored control algorithms and related workflow. All these topics are ultimately related although I am specifically interested in Hall sensored control only. As I understand these tools from STM are rather new and there is mismatch in the levels of their development.

I only started now this workflow: X-CUBE-MCSDK STM SDK Ver. 5.0.3 with it's MC Profiler, Nucleo-F303RE and X-NUCLEO-IHM08M1 expansion board , TrueStudio IDE with it's toolchain and 1KW BLDC Motor with 3 Hall sensors rated for 48V up to 28 amps.  So far I am quite impressed with the results and the quality of the code but the hard questions to the STM team will come too.

1st step : hardware preparations. Nucleo board was the easiest : just make sure the power is received from the expansion board' DC-DC converter instead of USB power. User manual is clear about it.

X-NUCLEO-IHM08M1 expansion board was not that easy: default setup is for 1 shunt and needs careful re-soldering of the high current jumpers to allow 3-shunt current measuring configuration which is required for FOC algorithm.

The confusing part here is confusing information in the user manual about 3 capacitors C3, C5, C7 - it is only clear that for FOC algorithm they should be removed. Whether they should stay or can be removed for 6-step control is not clear. I asked this question on the forum but so far no answer.

2nd step: Motor Profiler run - my motor is 3000RPM, 1KW, 48V , max 28A , 6 poles BLDC with Hall sensors. By lying to the profiler I got max 1300RPM, 10 A, 24V, 3 pole pairs in a profile. (To Abdul:  you can also lie about voltage , amps and RPM but not about the pole pairs - wrong pole pairs should always confuse the software driver). Connection was smooth from the start and profiler did quite intelligent algorithm figuring out all the data about the motor. I'd prefer to know where the Profiler saves the profiled file but no information was found anywhere - luckily MCSDK  Workbench found that file while I never saw it And fun part is: I could run the motor by a profiler without even uploading any code to the MCU !

Note: I ran the Profiler as stand alone (without running MCSDK Workbench). Workbench allows to run the Profiler only when starting a new project. I'd like to see the 'Profiler' starting button always when in a default state of the Workbench and be able to update profile for a given project - right now this is not possible.

3rd step: running MCSDK Workbench - well designed software. Most parameters for all the modules of the system already populated as a result of making the choice of the boards: in my case Nucleo-F303RE and X-NUCLEO-IHM08M1 expansion board . I could verify some of IHM08M1 expansion board specs by comparing them to those provided in the X-NUCLEO-IHM08M1 user manual for the FOC mode (table on page 27) - exact match. Very convenient button allowing to see the functional pin assignment of the MCU for the given motor control system - beautiful (I still remember how much time I spent in the past trying to figure this out with another MCU solution).

At this step assign the Output Folder Options - which is actually choosing the IDE and toolchains environment. I chose TrueStudio and then generated code for it and imported that code into TrueStudio, rebuild and uploaded to the target.

Then ran Workbench again to start 'playing' with Monitor . Started easy and the basic window is nice. Motor ran smooth after first ramping up to higher RPM but then lowering to the defined on the ramp gauge. The ramp gauge is in essence input of the required rotational speed.  It is easy to change specs in the Workbench and try running it here. For ex. I change the PWM frequency and then run it... and listen if I like the 'tune pitch'

Note: about the low speed rotation start. The motor controller can start ramping up at any speed but it does not stay at it if the sped set at below the 500 RPM. I see this as the motor' feature, not the motor controller. My motor is high inertia motor with heavy rotor requiring 48 rated volts and torque (means current) high enough to keep rotation of heavy rotor at the low speed. Given the low voltage I lied to the profiler and low max current I lied too, the controller cannot simply provide needed current (=torque=power) to sustain the needed rotation at lower than 500RPM. This should be expected.

----------------------------------------------

Now questions :

Why does STM present X-CUBE-MCSDK as 'FOC motor control' ? There is FOC control mode in there for sure but it is only when 3-shunt chosen and backEMF used for FOC algorithm calculations. When Hall sensor is chosen in the setup and only 1 shunt instead of 3 it cannot be FOC any more but rather 6-step control. In other words I see it as a library and a complete workflow for ALL types of motor control: FOC or Sensor based 1-shunt 6-step control.

Am I missing something?

I hope somebody from STM team will read this to answer...