2019-10-03 11:54 AM
We generate the firmware code using the Motor Control Workbench that calls the STMCubeMX that then calls the STMCubeIDE. We were able to successfully compile the firmware this way using the IAR IDE, but we get many compiler errors with the STMCubeIDE. An example of the errors is:
../Drivers/STM32F3xx_HAL_Driver/Src/stm32f3xx_hal_timebase_rtc_alarm_template.c:98:1: error: unknown type name 'RTC_HandleTypeDef'; did you mean 'I2C_HandleTypeDef' RTC_HandleTypeDef hRTC_Handle;
2021-07-06 04:23 PM
They've done this to a while load of questions recently, my inbox has been flamed with notifications of it.
I gave up with the mcsdk and wrote my own FOC algorithm, took less effort than debugging the impenetrable st libraries, working out why it just stops responding, working out how to deal with different motor parameters...
The infineon one works out of the box, but you quickly hit limits with cannot use any sensors, can't manage break states etc.
What hardware did you move to that side have a working firmware DCyr? I have so far not found any.
2021-07-06 05:10 PM
Hi DMolo, You are obviously way past my level of expertise if you wrote an FOC algorithm! I can't help you with your question about which hardware works, since I gave up struggling with ST hardware and software 2 years ago because none of the 4 boards would properly drive the BLDC motor we were using. One of ST's evaluation boards wouldn't even connect to the system to drive the board. I had to solder wires onto the SMD components to communicate with it!!! We had a Chinese company design and build a prototype ESC that worked far better than any of the ST evaluation boards, but we eventually developed our own ESC with open software systems available on Github.com. It sounds like things haven't gotten any better with another 2 years...
2021-07-07 12:28 AM
Hi DCyr
Thanks for your answer.
What I am trying to say (and for a lot of other topics in STM) is .... ST have not fixed this bug which is now apparently 2 years old!!!
No, the problem is 'new' to me. Previously (several years ago) I used the ST libs when they were new. They worked with these boards.
Now they are broken.
I just want to spin a BLDC for a prospective client - I'll probably do that in FORTH in a few minutes
They probably work flawlessly on the expensive non-ST tools
Pathetic - yes
Will I move on? - Yes You and DMolo point me to the same recommended path.
Thansk for tthe heads up.
2021-07-07 12:32 AM
Hi DMolo,
Thanks for the quick response.
I'll probably write my own drivers in FORTH
At least you 2 gentlemen have informed me that ST have not improved the quality of their product and that I should look elsewhere.
Field/Park is well documented and there are other libs from most of the big manufacturers. There's probably stuff on GIt as well.
They seem to be adding all kinds of junk like AI , NN etc, yet not spending time on getting the basics right.
Even the design of HAL *****
2021-07-07 12:43 AM
Hello,
Could you detail the version of the tool you are using ( cubeMX cubeIDE) and the HAL library.
We use cubeIDE in our automated testing suite and all our tests compiled and passed with cubeIDE.
It will help us a lot to understand why we did not catch your issue during our tests, so do not hesitate to give us all the clues that could help us to reproduce your issue.
Just a quick advise, could you try to generate a project in a fresh new workspace, and confirm that the problem is still present ? Thanks.
Cedric
2021-07-07 01:43 AM
Hi Cedric.
The versions are all the latest - both legacy and "Y" downloaded Monday 5th July
Cube IDE 1.6.1 Build 9958_2021_03_26_1446 (UTC)
MC_SDK_5.4.6
MC_SDK_5.Y.1
They are kept updated by the automated tools, this was checked immediately after the problem.
The projects were all brand new - simply followed the instructions for
I tried several cases (FOC, 6 step, Advanced Potentiameter) for the standard IHM001 (STM32F302 and IHM007 L6230 board)
I generated for the Cube compiler
I also tried the Attolic since i have this installed
The dev machine is a WIndows 10 machine
I tried adding library paths but gave up after adding about 5 different paths
Common problems included
I suggest you are not zeroing out your dev machine build (teardown between regressions) and installing CUBE, MCWB on testing each compile
I think you have some eclipse settings that are hiding these items from a new machine, but have been set to unhide them on your test system
Otherwise the converse - by using cube for other projects, eclipse has been told to ignore for instance the _LL_ headers.
2021-07-07 01:47 AM
F302 does have floating point FPU.
You might need to import into the cubemx and generate code, otherwise it'll miss all the library functions.
Maybe you're already doing that but... It would definitely explain the issues you're seeing.
2021-07-07 02:32 AM
Also, though i haven't tried for a few months, the cubeide project generation option is not functional/you have to generate for one of the others and import the project which is a pain.
2021-07-07 02:32 AM
Hi DMolo
I did import into the IDE since ther is no other way of opening it ... the supposed link from the MCSDK generator to open the project does not work.
The compiler says ther is no FPU in the MCU it is generating for. Perhaps that is also messed up in the generator.
Let's see what CedricH comes back with - at least he is with ST and may be able to push some buttons.
Download SDK, hoose example, generate compile SHOULD work out the box. :)
2021-07-07 02:40 AM
Just to be clear, there's 2 lots of generating required... Generate in the mcsdk and generate again in cubemx.
Mcsdk generates motor control libraries, but they call HAL and LL which are generated by the cube mx.
But yeah... It's generally a mess that eats it's face at the slightest opportunity. Who knows what the automated test suite actually tests for.
The end result is very efficient motor control but I've burnt a lot of hours on this. And never got to a stage where I'm confident i can make changes and really on it still working.