Bug Report MCSDK 5.Y.3: Generated code has macro redefinition and undefined identifier errors

[Quentin Ch]

Hello,

I'm experimenting with the Motor Control SDK toolchain (MCSDK v5.Y.3).

1. I set up the config in Motor Control Workbench (the .stmcx file is attached, I changed the extension to .txt so that I can upload it...)
2. After having check all pin assignments are OK, I generate the project for IAR v8, CubeMX 6.1.1, with HAL drivers type, firmware package 1.25.2. The generation complete without warning nor error.
3. I then open the IAR project that has just been generated and try to build it as-it-is. I got the warning and the error below:

Macro redefinition:

Warning[Pa181]: incompatible redefinition of macro "SPD_TIM_M1_IRQHandler" (declared at line 173) ***\Inc\parameters_conversion.h 178

=> I set a different timer for the hall sensors and for the auxiliary speed sensor (quadrature encoder), but the same symbole SPD_TIM_M1_IRQHandler is defined for both timers:

#define SPD_TIM_M1_IRQHandler TIM2_IRQHandler
#define SPD_TIM_M1_IRQHandler TIM3_IRQHandler

I expected to be able to choose different timers, or to get a warning if I use different ones.

A workaround is to use the same timer for both in MotorControl Workbench.

Undefined identifier:

Error[Pe020]: identifier "VirtualSpeedSensorM1" is undefined ***\Src\mc_tasks.c 162

=> This symbol is defined in .../Src/mc_config.c. However other symbols like

However other symbols like PIDIqHandle_M1 are also defined in this same file and also used in mc_tasks.c, and they don't triggers error.

Maybe a missing include or external reference ?

I expected the generated code to compile out-of-the box.

Additional info:

The error and the warning also happen if the code is generated with LL drivers instead of HAL drivers, in MotorControl Workbench.

Thanks for your insight :)

[cedric H]

Hello @Quentin Ch​ ,

Thanks a lot for the high quality of your bug report.

The configuration with two sensors is currently not supported.

Main sensors and auxiliary sensors are proposed to switch from sensors to sensor-less algorithms.

In the next workbench generation, we will prevent our user to select two sensors as you did (encoder + hall sensors).

Best regards

Cedric

[Quentin Ch]

Just to understand, it's to switch between sensored and sensorless at run-time, using one or the other sensor ?

I initially though the two speed estimations were fused to increase the accuracy.

Or that I could get rid of the alignment process but have high resolution speed by using Hall + encoders.

[cedric H]

> Just to understand, it's to switch between sensored and sensorless at run-time, using one or the other sensor ?

That is the plan but not yet available in API SDK.

From the 5.Y.4, we provide API to have access to auxiliary sensor information from application code:

int16_t MC_GetMecAuxiliarySpeedAverageMotor*(void)

Float version :

MC_GetMecAuxiliarySpeedAverageMotor*_F(void)

int16_t MC_GetAuxiliaryElAngledppMotor*(void)

>I initially though the two speed estimations were fused to increase the accuracy.

No, the encoder will always be the most accurate. If you have both, it would be the preferred option.

>Or that I could get rid of the alignment process but have high resolution speed by using Hall + encoders.

Hall sensors are aligned thanks to the "placement electrical angle" configuration in the motor parameter window.

Encoder angle is read from a timer, and this timer value must be 0 when the electrical angle is 0. It is why we align the rotor to 0, and reset the encoder timer once done.

But as mentioned before, our SDK does not support two hardware sensors simultaneously mainly because ou power boards do not support this feature as they share the same Pins between Encoder and Hall sensors.

Regards

Cedric