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

[DCyr]

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;

[cedric H]

Sorry I missed to react about his :

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

If you did not modify the IOC, you do not have to open cubeMX and generate again. It has already been done by the workbench. You just generate the code twice. Once the project is generated from the workbench you can just click on "Open Folder" and you will see that your complete project is already there.

Cedric

[shorai]

Hi Cedric,

Thank you for the explanation -it goes a long way to help me understand what I should be doing.

I tagged on to the thread since I was exeriencing the exact message described in it.

If I read this correctly, I should use Generate from the MC Workbench only when creating a new project from the workbench. ANytime I use it again on the same project it is likely to cause problems.

Th examples have already been generated, so I should only ever update them.

Is this correct?

So the criticla points from this thread are

• Only generate new projects once
• Only Update examples because they are already generated
• Use stand alone Cube MX on motor control projects
• Be aware that there are technical issues that have not yet been cleared by the dev team (backup, backup, backup) AND version control
• It may be better in the interrim to adjust parameters in code rather than .ioc
• It may be better in the interrim to add IP via code so as not to confuse the code update

These last two are a bit of a pain, may be unnecessary unless you are working against a deadline. They are easy enough to do. An easy work around would be tot create an .ioc specifically to initialise these pins, generate to separate files, then copy these files in to the MC project.

Perhaps the Generate button needs to either be greyed out, or carry a warning dialog if invoked and the files exist.

Perhaps the .ioc can be tagged so that CubeIDE->Mx cannot open it (or IDE can spawn External CubeMX ?).

Thanks for the help.

Chris

[cedric H]

Hello Chris,

I will try to answer point by point.

" I should use Generate from the MC Workbench only when creating a new project from the workbench. ANytime I use it again on the same project it is likely to cause problems."

Not really. When you start a project from scratch, you do not have the choice, only the generate button can be clicked, as there is nothing to update.

The rule of thumb, is that as far as you do not change the IOC file generated clicking on generate button is the safest solution.

The trick to understand here is that starting from an example, is NOT starting from scratch. We provide within the example an IOC that you must not override to keep the example functional. This is why we ask you to click on the update button in the provided readme.txt file. The purpose here is to allow the user to change only the motor parameters.

"So the criticla points from this thread are

• Only generate new projects once

You can generate project multiple time, clicking on generate button will guarantee you that the IOC is always coherent but written from scratch.

• Only Update examples because they are already generated

Almost correct ! Whole project is not generated, but the IOC file is already provided. It has just to be updated with your motor parameters. So yes only click on Update button when you start from an example (as stated in the readme.txt file 😉 )

• Use stand alone Cube MX on motor control projects

This is our recommendation today.

For the first generation you do not really have the choice. cubeMX version embedded inside cubeIDE is not proposed amongst the possible choices. An action is on going to detect it but It is not the case yet.

Once the code is generated, modification of the IOC could be done by cubeMX or embedded cubeIDE version. I tested both successfully but our preferred way in the dev team is to use standalone cubeMX version. It is an old habit as the cubeMX embedded in cubeIDE is a pretty new feature.

• Be aware that there are technical issues that have not yet been cleared by the dev team (backup, backup, backup) AND version control

Not sure what are you referring to here,

• It may be better in the interrim to adjust parameters in code rather than .ioc
• It may be better in the interrim to add IP via code so as not to confuse the code update

If you need to add IPs or modify the IOC, the safest way to proceed is to do this inside cubeMX, and once the IOC is modified generate the code from cubeMX only. You should avoid to use the MC Workbench and click on update button to update an IOC modified by cubeMX excepting you completely understand what you are modifying.

"They are easy enough to do. An easy work around would be tot create an .ioc specifically to initialise these pins, generate to separate files, then copy these files in to the MC project."

We are working hard to iron this part, For the time being the best advice I can give you is to avoid round-trip between cubeMX and MC Workbench,

Regards

Cedric