Associate III

Question

Errors compiling with STMCubeIDE likely because module libraries aren't included. How do you include missing libraries? Or could it be something else?

Forum|Forum|6 years ago
October 3, 2019
33 replies
14802 views

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;

STM32 Motor Control

This topic has been closed for replies.

Show previous replies

DMolo

Associate III

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.

shorai

Associate III

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 *****

DCyrAuthor

Associate III

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...

shorai

Associate III

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

A new project from an example
A new project from defined motherboard

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

RTC not configured
Looking for RTOS when no RTOS specified
Breaks when RTOS specified
Many of the MSWB lib paths not included
_LL_ libs not found (either with HAL or LL selected). They are in the distro paths, but not in the Eclipse rendition. ie. I can see STM32F3xx_HAL_***.h but not _LL_.h
MCWB and CMSIS headers not available
Tries to include stuff I doubt we need -
Tries to compile with Floating Point processor (F302 does not have)
code generation errors - macros not expanding e.g. #include some text not in quotes. I am not at that machine now, but will forward you the message later today

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.

DMolo

Associate III

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.

DMolo

Associate III

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.

shorai

Associate III

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. :)

DMolo

Associate III

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.

shorai

Associate III

Hi DMolo and CedricH

I've done a bit more of a deep dive into this (hence the time delay).

I've elected to use only the 5.Y.1 version for ow

Yes, I ihave been doing the dual generation

I still have problms, but have removed some potential problems and identified some other possible culprits.

CubeMX - My CubeIDE says everything is up to date (really)

The Cube MX on my Desktop was an old version, which I updated to latest 6.1.2
With this version, I can generate the correct Drivers/HAL...../*.* including all the _LL_ files (yay)

So now we have some new information

RTC is still not switched on for the projects I tried (Potentiometer and otentimeter advanced)
For Potentiometer I get a library warning FW_F3 V1.11.2 (old version) should be upgaded to FW_F3 V1.11.2 (SAME VERSION? Huh)
Sorry cant paste this because some idiot put the message in a system modal rread only text box.
The tools are full of these - the MCSDK generator has a great log on the right hand side ...... sorry, cant cut and paste to show you my runtime versions (FIXME)
If I change the .ioc to switch on RTC clock (required for compile) the _LL_ and all the new .h files in Drvers/HAL/Inc.... disappear (see point 2 above)
In Potentiometer/STM32CubeIDE/Drivers/*HAL/ there are NO files
The Potentimeter example keeps the Build tool (hammer) greyed out

Looks like the CubeMX running in the IDE may be different from the one on the Desktop. I therefore switched to the one on the desktop

I am now running MCWB -> Generate

Desktop CubeMX ->Generate

IDE -> Import (tried both existing project and file system imports)

When importing there are 2 projects marked

a) In the pointed folder - imports correctly with all the _LL_ files

b) In the pointed folder/STM32CubeIDE only contains a small subset of the Drivers/...HAL.../Inc files

This may be the major problem since the missing files break the compile

I cannot find a file filter in Eclipse that has hidden these files

Cube seems to remember some of the errors even after the project is deleted from a workspace hen regenerated and re-imported

According to the readme, MDK, EWarm and TrueStudio are supported. This has not been updated to reflect Cube. Peraps no-one has tested this with Cube.

The deprecated tool chains are not marke as such.

"But yeah... It's generally a mess that eats it's face at the slightest opportunity." haha love it

There are now NO build configurations, targets or the ability to build the project in the CubeiDE

Great to know the code produced is eventually efficient!

DCyrAuthor

Associate III

Since I initiated this thread, I still get updates on progress. However, I gave up 2 years ago trying to make anything of the ST hardware and software, so I wish you both lots of luck getting something going. I wasted a year with this project, having bought 4 ST evaluation boards. When one wouldn't work adequately, I tried the next... Each one eventually ran our BLDC motor to varying degrees, but couldn't run it to rated RPM and torque. The Motor Profiler couldn't capture the motor parameters because they were supposedly out of range. To top it off, I asked for the code for the Motor Control Workbench because the equivalent is required to control the evaluation board firmware to drive the motor. ST flatly refused. That made the decision a little easier to abandon ST and their faulty systems. (Yes, I am angry for wasting so much time and money) Good luck guys!

cedric H

Technical Moderator

Hello crowse,

The project generation flow requires a standalone cubeMX version for the time being.

The "Target Toolchain" selection is used to build the correct project files only. So in case of cubeIDE, it will create the STM32CubeIDE folder with the correct ".project" file.

Double clicking on ".project" file import the generated project into the workspace. As far as I can test, I am able to compile the project without any warnings nor errors.

You mention that RTC is "still" not switched on.

you are right, this is not required by the Motor Control library and therefore we have no plan to enable it by default. This is very application specific, and out of the scope of the Motor control workbench to enable it.

I tried to enable the RTC clock from the cubeMX embedded inside cubeIDE, and have seen the issue you had regarding the request of the F3 firmware version that is already available. I will enter a bug report for cubeIDE team.

After skipping the request to download the F3 HAL version that I already have, I enabled the RTC and re-generate the code from cubeIDE. Here again, I was able to recompile the project without warnings nor errors, and the new main.c contains as expected the initialization code of the RTC.

Regarding Potentiometer example, it is important to open it from the example list presented at the workbench startup screen. and generate the project by clicking on the update button.

I did it just now, and once again did not find any compilation issue.

To go further, I opened the IOC file with cubeIDE, enabled another IP, re-genrerate the code and re-compile it.

I did not faced any issue.

In a more general way, If you have to do some modification in the IOC, I would suggest you to do them with cubeMX standalone application, and re-generate the code from this version.

But, from the test I did so far, excepting the issue around the HAL library that were requested by cubeMX despite the fact that they were already available, I did not face any issues.

Did you change other settings inside project generator parameters ? I am still trying to reproduce any of your issues.

For your information, all projects are compiled and test with cubeIDE.

I think it would help me if you can share an IOC file that you modified (with standalone cubeMX or cubeIDE) and lead to a breaking project.

Best regards

Cedric

shorai

Associate III

Hi Cedric

Thanks for the quick reply.

Wierd?

Regardless of target toolchain, with the updates I noted previously, stubs are generated for MDK(2 versions), IAR, Cube, SW4ST and Atolic (much like one finds in the projects/ folder of CubeIDE repository.

I've been MX->Generate (rather than update cause its a new project?) then using File->Import, I'll try Update and click 0n the .project file (though this tends to open Atolic on my machine)

The reason I enable RTC is because the error messages from the compile indicate that RTC_ functions cannot be found. This is correct since the Drivers/..._HAL_/ does not show HAL libraries for RTC and the code request RTC.

no changes.

I can zip the entire project and send that to you - it's plain vanilla example, no changes until an error is reported. I'll put it on my Google drive for you.

cedric H

Technical Moderator

Ok, now I understand your RTC issue. It comes from a misalignment between your HAL library and your cubeMX version.

I think if you update both cubeMX and HAL, the issue will disappear.

After a fresh installation of cubeIDE, if you click on the executable at the first launch it will ask you if you want to associate the ".project" file with this new version. this is usually what I do when I upgrade from a version to another one.

Do not hesitate to post your project it will help me to understand your issues.

Thanks a lot

Cedric

shorai

Associate III

Hi edric

Here is a link to a zip on my google drive, you should be able to get the file from there

https://drive.google.com/file/d/18E5qiGnVwscVaU5xeS4Z41z48Ledr3a0/view?usp=sharing

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded