Drive polarity in motor control workbench 5.2- does this work?

[MRyan.7]

We have a custom board that uses an STM32F303 processor. The gate driver chosen for it is not the STEVAL-001ESC IC. The ST IC has the polarity of the low side driver 'active low'. The IC we are using has the low side driver as 'active high'. However, when we make this change, it looks like the phases are being turned on incorrectly.

Diffing the generated software with the only change being the MCW 5.2 update from active low to active high results in 5 files being changed, none of which are C or H files. It is .ioc, .elf, .log, etc files. The *.ioc file seems to show the correct changes, for example this:

MotorControl.PHASE_VL_POLARITY=L_ACTIVE_LOW

changed to this:

MotorControl.PHASE_VL_POLARITY=L_ACTIVE_HIGH

occurs also on the other 2 phases.

However, there seems to be no corresponding C or H code changes and the output to the gate drivers on the board seems to not change either. So it seems like it is perhaps not incorporating this change. We have successfully built and run the stock firmware for STEVAL-001ESC on that board, and are reasonably comfortable with the code.

Note that on this custom board, we have overriden the GPIO locks in the generated code and did a quick test to verify that the hardware / pinout was correct. In this case, we skipped the PWM and directly commanded the gate driver pins with the HAL_GPIO_WritePin function. In this case, where the set/reset is directly written to the pin, all the hardware worked correctly and the motor lurched as expected.

So, can anyone answer these:

1. Is drive polarity in the MCW 5.2 GUI a supported feature?
2. If so, how is that polarity being implemented? We don't see it in any of the C files.
3. If not, can anyone suggest the best place to manually implement this in the generated code?

Thanks for your help (and Happy New Year!)

[cedric H]

Dear Ryan,

The drive polarity is a supported feature. And it is mandatory for us to support it as we have both configurations existing within ST products.

The consequence of your configuration can be seen in the main.c file. I did the test with code generated thanks to HAL lib.

Following lines are generated inside the  MX_TIM1_Init function of main.c :

- with active LOW for low side :

 sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH;

 sConfigOC.OCNPolarity = TIM_OCNPOLARITY_LOW;

- with active HIGH for low side :

 sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH;

 sConfigOC.OCNPolarity = TIM_OCNPOLARITY_HIGH;

Just a remark, you mentioned the STEVAL-001ESC in your post. I do not know if you take it as a reference, but if you have a  STM32F303 processor, i would advise you to start with a Nucleo board instead. The STM32F303 has 4 ADCs, but unfortunately, the current reading is done with only one ADC. It means that with a 3 shunt topology (which is the case of STEVAL-001ESC) we read two phases sequentially. It is better to take benefit of using 2 ADCs to sample the current of two phases exactly in the same time.

Hope it helps

Cedric

[MRyan.7]

Hello Cedric,

Thank you for the reply. I had found the same part of main.c. However, when I change polarity in the workbench GUI, and then do a 'update' (not a full generation of code, but an update to the existing(, then those lines never change, regardless of the polarity I select. Can you confirm if you did an update or a full generation? Also, have there been any updates to the Workbench software (I'm using 5.2.0).

Also, thank you for the advice re: STEVAL and the Nucleo. I have some nucleo boards also. Which would you most likely recommend to take advantage of the 2 ADC read?

Thank you!

[MRyan.7]

Cedric,

I just tried a full generation instead of an update of the code within 5.2.0. The full generation DOES provide the changes to polarity. However, the incremental update selection does NOT change those lines! I would recommend your team look at this. If you can reproduce, I think it is important because other settings might not carry over in an update either!

Thank you.

[cedric H · Accepted solution]

Update button is a kind of workaround because we do use two separate tools to generate the project. The Workbench generates the IOC and cubeMX generate the project with initialization code thanks to this IOC. The purpose of the update button is to not override the IOC if it has been modified by the customer.

The flow is the following :

Project is initially generated by the MC workbench.

IOC is loaded with cubeMX

User add other peripherals, (SPI, additional GPIOs etc...) and save the customized IOC

User wants to update the Motor control parameters inside his customized IOC.

If he applies generate, he will loose his IOC.

the Update button will modify only the MotorControl IP inside the IOC.

In your case it will not do the job because the polarity is a timer configuration :

TIM1.OCNPolarity_1=TIM_OCNPOLARITY_HIGH

TIM1.OCNPolarity_2=TIM_OCNPOLARITY_HIGH

TIM1.OCNPolarity_3=TIM_OCNPOLARITY_HIGH

So it will not be changed. I know it is confusing because you also have those fields

MotorControl.PHASE_UL_POLARITY=L_ACTIVE_HIGH

MotorControl.PHASE_VL_POLARITY=L_ACTIVE_HIGH

MotorControl.PHASE_WL_POLARITY=L_ACTIVE_HIGH

That will be updated because they do belong to MotorControl IP, but they are not used in this context....

We are planning to merge the Workbench into cubeMX to avoid this kind of limitations in the future..

Regarding NUCLEO board, F303RE or F446 are fines. F302R8 and F401 have only 1 ADC.

Regards

Cedric

[MRyan.7]

Perfect, that makes sense! Thank you for your help Cedric!

[Laurent Ca...]

The question has been moved from the section "Motor Control Hardware" to the "STM32 Motor Control" section (the question is about the STM32 MC SDK). 

Best regards