BUGREPORT MCSDK 5.4.3 (and temporary fix)

[chaaalyy]

Hi,

since a couple of days i tried to get the STEVAL-ROBOT-1 up and running properly. But as i mentioned here:

https://community.st.com/s/question/0D53W000003yGcdSAE/to-choice-a-kit-for-pmsm

yesterday, i got more problems, than i would have expected from libraries, provided by a "mature" company like ST.

Ok, giving up is not an option... So meanwhile i figured out, what´s wrong (After around 30 hours of search...). But step by step:

After many problems, importing the (actual) STSW-ROBOT-1 into cubeIDE and getting it to be built, i faced problems with unreliable position control, unexpected behaviour with torque regulation, unexpected moving motor and so on. Until yesterday i thought, it´s maybe just an error in some overflow calculation, but THIS is even worse:

In the file trajectory_ctrl.c , located in the folder \MCSDK_v5.4.3\MotorControl\MCSDK\MCLib\Any\Src , Lines 341 - 354 , the function void TC_EncoderReset(PosCtrl_Handle_t *pHandle) is the problem:

This function is called within the EXTI0_1_IRQHandler (void) , located in stm32f0xx_mc_it.c , EVERY time, the index pin of the provided encoder is passed by. So far, so good...

But why the hell, also EVERY time within these functions, ENC_SetMecAngle(pHandle->pENC , pHandle->MecAngleOffset) is called ??? Of course, the irq handler needs some time (not much, but anyway...) to run through. And in THIS time, of course the motor runs a few steps further. Now you take the formerly measured counter values and reset the counter to a PREVIOUS captured value ??? (Sorry, i´m just a little bit upset about so much stupidity...)

Of course this leads to absolutely undefined behaviour of the motor, up to loosing synchronisation. If you run the motor repeatedly just full revolutions (360 degree), after a while you can see, it´s definitely not "on track" anymore.

The solution is simple: placing the ENC_SetMecAngle - function within the if / else brackets. So it´s reliably called, when needed to align the motor with the encoder and afterwards, it´s just not called anymore. I attached the correted file here.

This affects ALL projects, with EVERY hardware ! Not just the STEVAL-ROBOT-1-Kit !

Ok, the next problem: As i stated in the thread, i linked above, also the motor settings and board parameters are more than just lousy. Resistance and inductivity not set correctly, Amperes just crippled, and so on, and so on ...

I made a quick fix (not perfect, still some tuning needed, but these settings work FAR better, than the original ones from ST) I attached two files (drive_parameters.h and pmsm_motor_parameters.h) with the settings, just replace them in the folder \Inc (not visible in cubeIDE project explorer, so open the folder directly in your workspace).

Last, but not least: For everybody, who doesn´t believe in these errors, provided by ST and also has no time to set up a modbus connection, i made a quick and dirty "check" run in main.c. Two possibilities, comment out the one, you don´t need. Begin with the 360 degree steps to see the behaviour without the corrected trajectory, then make the corrections and let it run for an hour or so ... NO position errors and NO unexpected behaviour or even movements anymore. For the 400 revs - routine, just running forward and backward for 10 secs each: PID settings need some more fine tuning, so it "overruns" a little bit, before PID corrects the position 😉

Edit: For everybody, who is wondering about that "encCounterValue = TIM3->CNT;" in main.c ... Add it to your live expressions while debugging to check the "stop" point after each movement... Should be within +/- 3 encoder steps, even after 100000 x moving 360 degrees forward.....

[Claire O.]

The main changes are the introduction of a new STM32F3 dual board for PFC (STEVAL-CTM010V1), a workaround to palliate STM32G4xx Cut 2.2 injected ADC conversion issue and many many bug fixes... (please check release notes!)

We will make shortly an announcement in the forum.

Thanks and best regards,

Claire