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-07 05:32 AM
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)
So now we have some new information
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!
2021-07-07 06:16 AM
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!
2021-07-07 07:27 AM
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
2021-07-07 07:38 AM
Sorry I have not seen this post before :
"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."
This is not correct.
The generate button from the mcsdk generates a complete project, containing everything you need, Motor control library and HAL/LL libraries in a folder located at the same level than your stmcx file. ( this button actually calls cubeMX gnerator)
If you want to modify the IOC generated by the workbench in order to enable your own IP required by your application, then you have the possibility to open the IOC file generated with cubeMX, do your modifications (be careful to not break the configuration done by the MC Workbench) and then you have to re-generate the code from cubeMX.
Be aware that if you do not need to modify the generated IOC, you could generate a project without having to open cubeMX.
cubeMX must be installed on your system as it is called by the workbench at the generation stage.
I hope I am clear. otherwise do not hesitate to ask.
Regards
Cedric
2021-07-07 07:46 AM
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.
2021-07-07 08:12 AM
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
2021-07-07 08:19 AM
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
2021-07-07 08:33 AM
At th etime of the install on this machine, cube was new and unstable, Attolic was the preferred mapping for .project files as it was the preferred tool from ST
MX was upgraded this morning. HALS on monday - they should be the same.
2021-07-07 09:46 AM
Hi Cedric,
OK I have progress.
I have now compiled both the Potemntiometer and potentiometer advanced projects
I deleted the former projects.
I uninstalled Attolic
I changed the .project link to open STMCubeIDE instead of Atollic
From MCWorkbench, I used the Update button instead of Generate (Generate should be removed or disabled if it does not work)
I closed MCW and opened Cube MX
I generated code (no changes to .ioc)
I closed CubeMx (it asked to save .ioc which I saved
I opened File Explorer and clicked on the .project file
This opened CubeIDE and reported 'Project imported sucessfully'
I compiled the project(s)
The projects compiled and linked with no errors
I will commence testing and modifying tomorrow
many thanks for the assistance.
Looks like the toos are still flakey and need to be stabilised.
Thanks to CedricH, DCyr and DMolo
2021-07-07 10:27 AM
Ok,
Happy to read some good news.
Update and Generate are a bit tricky but worth to understand. Let me try an explanation.
The Workbench generate an IOC. this IOC is complete from motor control point of view, but additional IPs can be needed depending on the application.
The update button will guarantee that only the MOTOCONTROL stuff of the IOC will be modified.
The idea behind, is this one :
Then the Update button is what he needs. It will update only the MotorControl part of the IOC.
In the case of potentiometer example, this is exactly what we use. The potentiometer is connected to an additional ADC channel, through an additional pin called POTENTIOMETER. This ioc is copied with your project when you save it the first time. If you click on generate, you will erase the IOC we provide with the potentiometer, so the example will not work because the Potentiometer pin will not be configured.
The update button is proposed only when an existing ioc with the same name than the stmcx file is detected.
I hope that the concept is clear.
Now, there are a lot of limitations that are difficult to catch. The biggest limitation is that when you want to update an IOC, only few modifications from the Workbench are possible, but nothing will warn you. We are working to avoid these traps in the future.
For example, the workbench let you change the PWM frequency. this PWM frequency will be used to change the auto-reload value of the PWM Timer. So the information is stored inside the timer section of the IOC. the Update button is not allowed to change the Timer section, only the MotorControl part as explained before, so changing the PWM frequency and generating the project with Update button will lead to a non working project without any warnings from the tool.
We are fully aware of those issues and a complete new Workbench is under heavy development.
I hope that things are more clear now.
On my side I entered a ticket on cubeIDE side to fix the request of lib download while they are already available.
For the rest, from all the trials I did, I did not see any generation issue.
If you agree I think that this two years old post can be closed now. To be honest I do not really understand why a ST guys reactivated it.
Regards
Cedric