cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 F0 + 6-Step PWM Glitchy - Need Advice

GustavEckerbom
Associate II

Hi there,

I'm writing this post because I have encountered a potential bug/firmware issue with the MC firmware versions FW1.11.4/FW1.11.5 for the F0 fam, and I'm unsure on how to proceed in diagnosing the cause of this problem.

Background:
I want to use a chip from the F0 family to run the six-step algorithm with back EMF sensing for speed and position feedback. I have successfully spun my motor using this setup with a PWM frequency of 50 kHz, utilizing the F401RE Nucleo board and the IHM11M1 evaluation board.

As I move forward, I want to get the software running on ANY F0 MCU to begin with. For this purpose, I'm using the F030R8 Nucleo board, (which is availible in the supported boards in the MC workbench 6.3.0) , and have set up a project in the MC Workbench, which can be found appended to this post for inspection in the google drive link. In this project, I've reduced the PWM frequency to 10 kHz to decrease the MCU's workload.


https://drive.google.com/file/d/1iH10Fo9dF0ywQuWusjUGKnciRnWQMJNM/view?usp=sharing

Problematic Behavior:
When I try to start the motor through the Motor Pilot, the PWM output looks glitchy and irregular (see appended picture), and after a few seconds, the Motor Pilot reports "Port Open but no answer from the board." Note, I have not even connected the Nucleo boards and IHM11M1 board together at this point. I'm only using the control board.

GustavEckerbom_1-1719836748322.png

GustavEckerbom_5-1719840652627.png

 

The expected behaviour/output is shown in the picture below and I got this from a project using a F401RE nucleo board.
 

GustavEckerbom_6-1719841745950.png

Tested Countermeasures:

-) My first thought was that the application was still overloading the MCU. In an attempt to minimize the workload for testing purposes, I tried lowering the PWM frequency to 2 kHz and running the 6-step algorithm at a period of 5 times the PWM period (3 ms intervals).

-) I compared the generated IOC file for the F401RE and the F030R8 projects. The only difference I saw and could not explain was that in the timer 1 settings for the F030R8; the generated configuration from the MC Workbench did not preset the clock source to be used. I've tested setting it to use the internal clock.

-) I tested generating the project using both HAL and LL drivers for the peripherals.

-) I've created an inverter board using the recently released board designer for the MCU sitting on a Nucleo - F031K6 with the same resulting PWM outputs.

None of the tested countermeasures improved/noticeably changed the generated PWM outputs and the motor pilot behaves the same.


Also, there's no error generated and communicated to the motor pilot except from "board not answering".

Setup:
Nucleo board F030R8
Powerboard IHM11M1 (Not plugged in to the controlboard at the tests above, just trying to isolate this problem if there are more than one problem 😉 )
6-step algorithm with BEMF sensing position feedback
Tested PWM frequency: 2-10 kHz

Toolchain and Firmware:
MC workbench 6.3.0
CubeMX 6.11.0
STM32CubeIDE 
Tested both firmware package versions V1.11.4 (Recommended) and V1.11.5.

Questions:

-) Now, I've investigated all that I can think of to be the cause of this issue without success, so any input and direction in how to move on would be greatly appreciated.

-) Has someone out there succesfully setup a 6-step project using a MCU from the F0 family with back emf sensing for position and speed feedback and can provide any insights? What setup did you use? Perhaps this could it  reduce the space of where to look for errors.

Question added after edit in Italic:
-) I can't make sense of why the tim1 does not have a preset clocksource when generating a project from the MC workbench for controlboards hosting F0 MCU, can anyone elese make sense of that?

Thanks!

Best regards,

Gustav Eckerbom

2 REPLIES 2

I don't use the motor stuff by ST so don't know what's in it, but one significant difference between Cortex-M0 and Cortex-M4 is the hardware floating-point unit in the latter. 

JW

Thanks for taking the time to answer my post. I would be surprised if this is the issue. In the release notes of the X-Cube-MCSDK 6.3.0, ST states they've added support for the six-step algorithm for the F0 series. Also, in the same document, ST states that all F0 MCUs are supported by the Motor Control Workbench, which generates the IOC file that configure the peripherals needed. So my thinking is that this should all be properly handled by the pipeline.

Thanks for your input!