How to support multiple STM targets in a project

[Michael Uman]

Hello,

From time to time it is good to be able to target multiple STM devices for a project. In our case we are evaluating a number of chipsets and have eval boards for the various chips. What I want to do is to be able to generate a project which will build for each of the targets.

Firstly I cannot figure out how to change the target MCU from the project settings dialog. It seems that the MCU field is not editable. How can I change the target once the project has been generated? (Or do I need to regenerate from the .ioc file each time?)

Thank you,

Michael Uman

[Markus GIRDLAND]

For now you can't change MCU once a project has been generated.

We're working on a solution for this that will support multiple devices for a project but it has not yet been released.

[Michael Uman]

Hello Markus,

Thank you for the prompt reply. Im looking forward to seeing that feature in future releases of the STM32CubeIDE tool.

Michael Uman

Lead Software Engineer

Wunder-Bar

[joaoleao]

Do you already have any feedback about this feature? I was searching to have the same code, but for two diferrent MCU, that is possible?

[M_3]

Up!

I need to build my project for different processors (different memory sizes, IO).

Here is a thread about changing the target from the IDEs:

https://www.eevblog.com/forum/microcontrollers/stm32cubeide-retarget-to-a-different-mcu/msg3721888/#msg3721888

which referts to https://www.st.com/resource/en/user_manual/dm00104712-stm32cubemx-for-stm32-configuration-and-initialization-c-code-generation-stmicroelectronics.pdf , page 287 .

[Pavel A.]

@Markus GIRDLAND​ Perhaps, a way to merge several CubeIDE projects for different MCUs into one with several configurations?

Assign target MCU per configuration, for debugging ?

[Markus GIRDLAND]

If it would be possible from CubeMX point of view it's probably something we could implement in CubeIDE as well. We are relying heavily on the CubeMX part in CubeIDE for all project generation. For CDT projects, for example, we have more control and it's possible to change target.

[Pavel A.]

What I imagine is like, you create two CubeMX projects (or somehow clone a project for a different target).

Then generate a CDT project for each [with code].

Then somehow merge these CDT projects so that each source project becomes a configuration in the merged project.

Just thinking aloud...

I have a real customer with such Eclipse project: several configurations for various MCUs, and I'm adding a config for STM32 manually.

[alister]

Supported in Eclipse from day dot. Nothing to do with STM32CubeIDE.

1. Create projects for each product and processor
2. Create build configurations for each way you build the project
3. Organise your source code apart from the project directories, and able to be built many ways

[mattias norlander]

CubeMX does allow switching MCU to a certain extent, assuming you run the tool stand-alone. Inside CubeIDE this is not possible. Read more about what is possible and the limitations here:

https://community.st.com/s/article/mcu1-to-mcu2-migration-option-within-stm32cubeide

But as @Markus GIRDLAND​ and @alister​ points out, the CDT projects which are native Eclipse/CDT projects, does not care about MCU selection. CDT projects can be seen as MCU/core agnostic.

In the CDT projects each build configuration can target a different MCU. This is what you are looking for (use CubeIDe 1.7.0 and later for some bug fixes).

The issue however is that these projects are without ioc-file. Not managed by CubeMX, and completely empty (you don't get startup code, linker script, HAL, not even empty main.c). You certainly have to copy some files from STM32Cube firmware packages and/or your legacy projects to turn a CDT project into something useful.

How can we combine the best of two worlds, that is: CubeMX code generation + CDT project individual core per build config support?

• Let your real production project be a CDT project allowing to build/debug artifacts targeting different MCUs.
• Use the CubeMX generated projects mainly as sandboxes to play with device configurations and gain confidence.
  • Then manually copy across files and build settings from CubeMX project to the respective build configuration of the CDT projects as your development progresses.
• We could imagine also creating links for certain resources from the CubeMX projects into the corresponding build configuration of the CDT project!
  • But I think there is a high risk that CubeIDE would get out of sync with the file system when CubeMX deletes resources as a result of disabling some middleware or similar use case...

Would be highly interesting to get customer feedback as to how they manage building projects targeting multiple MCUs using CubeMX and/or CubeIDE.

I am pretty sure there are creative solutions out there... :)

[Pavel A.]

@mattias norlander​ This sounds good IMHO.

I can manually create a makefile CDT project; CubeIDE should be able to select the target MCU for the debugger,

and select the target toolchain so 'make' will just work. (nice to have. Cross tool prefix can be defined in the custom makefile as well).

What would be really great: open/import existing "generic" Eclipse CDT project (.project, .cproject, makefile) and "inject" the two above features into an existing configuration.

This would let me to start from existing CDT project for other processor, add a STM32 config, build it *and debug* in CubeIDE.

[mattias norlander]

I think your request to "inject" the two features, is the same as requested by Andrew here:

CubeIDE: Imported Eclipse 'C' Project incorrectly defines __cplusplus (st.com)

My reply was:

"There is no easy way to get rid of "the little stunt" without making more substantial changes.

Those changes are not justified by the moderate usage numbers we see related to CDT projects."

Let me know if I misunderstood the point.

I will re-discuss with the team, but I am not to hopeful that we can find a solution with justified effort.

As always - appreciate the feedback!

And remember that we scan the Idea Zone (st.com) on a weekly basis to qualify change request or new feature requests.

We do take the number of votes related to each idea into our consideration when qualifying the feedback.