2024-07-01 11:45 AM - edited 2024-07-02 09:40 AM
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.
The expected behaviour/output is shown in the picture below and I got this from a project using a F401RE nucleo board.
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
2024-07-01 11:25 PM
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
2024-07-02 09:36 AM
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!
2024-07-24 08:29 AM
Hi GustavEckerbom, the default setting of PWM frequency for a MCSDK project (i.e. X-NUCLEO-IHM11M1 + NUCLEO-F030R8) generated with WB6.3.0 is 15KHz. I read that you tested from 2KHz to 10KHz, but did you try with this 15KHz value?
Best regards.
Fabrice
2024-08-01 11:14 AM - edited 2024-08-01 11:15 AM
-
2024-08-01 11:17 AM
Hi there Fabrice,
Thank you for your reply!
From my understanding, the MC Workbench 6.3.0 also uses motor characteristics to determine the PWM frequency. For my specific motor, the default PWM frequency was set to 50 kHz (not 15 kHz), which displayed similar erroneous behavior. Suspecting that the microcontroller might be overloaded, I reduced the PWM frequency. However, even with other motors that the MCWB 6.3.0 configures to operate at lower PWM frequencies by default, I've encountered the same issues.
From your reply, it's unclear whether you have a setup that works as intended. If you do, could you share the setup you use that avoids this buggy behavior, including the toolchain versions and hardware specifications? I would greatly appreciate it!
Best regards,
Gustav Eckerbom
2024-08-13 03:23 AM
Quick update:
After returning after my holiday I reinstalled the MCSDK 6.3. STM32CubeIDE and cubeMX to the latest version and this particular problem was not present anymore.
Thanks for everyones input.