How can I duplicate a project in STM32CubeIDE?

[msch]

I have a project in a workspace in STM32CubeIDE, generated with STM32CubeMX. I would like to duplicate the entire project, including the .ioc information, to use as the starting point for a new project. How can I do this? I am amazed that this topic does not seem to be covered in the STM32CubeIDE User Guide.

If I copy and past the project in the STM32CubeIDE Project Explorer window, it does create a new project, but many names are still those of the old project, and various files are still referencing the old project.

This is such a common task to want to accomplish. How can there not be a straightforward way to do it?

[Pavel A.]

@msch​ It actually *is* this simple. I've used Atollic for few projects, then updated to CubeIDE, and this way still works for me. Of course you need be careful not to have any absolute paths.

The <storageModule moduleId="cdtBuildSystem ... thing in .cproject indeed is not renamed, but does no harm as you've noticed.

The .ioc file needs a manual fix, yes. After a short practice this is not a problem.

I delete the .mxproject files immediately, they do nothing good and are not required to use the MX.

So... would be nice to have but absolutely not a major issue or show stopper.

As for "CDT" projects - i's not clear what you mean by this. Maybe, unmanaged/makefile projects? Both managed and unmanaged types are "CDT".

Internal builder for managed builds does not leave behind a lot of junk generated makefiles. Less confusion for beginners.

-- pa

[Pavel A.]

And this is very cool, btw. Kudos to Tilen Majerle!

https://github.com/MaJerle/stm32-cube-cmake-vscode

[mattias norlander]

Ohh... There is no "automated process" for this. But I have a couple of things that makes life easier.

You are going to have to copy both files and settings manually from one project to another. It might be easier to launch two instances of CubeIDE when copying the build settings. File copy is easy drag-drop in one IDE instance. But for build setting you can only have the build settings dialog of one project open concurrently. Hence I would say start the new CDT project in a new workspace initially. Especially if your migrating many projects from MX to CDT 🙂

My migration process would be roughly (maybe I already wrote it in another thread?):

• Create a new CDT project: File > New > C/C++ Project > C Managed Build > Empty Project > MCU ARM GCC > ...
• FOLDERS / FILES: Drag and drop over the folders / files you need
  • CAREFUL:
    • Make sure you "copy" folders/files instead of moving or creating links...
    • This also assumes that the project you are copying from contains the files you need physically! Not linked resources.
• BUILD SETTINGS:
  • CAUTION: Be careful to which build configuration you copy each settingto assuming you have at least a Debug and Release config...
  • Try to batch copy-paste settings:

You can do the same thing with symbols

The rest of the settings has to be reviewed manually. But t least this will simplify the most painful exercise...

• BUILD: Build your project. Typically one has forgotten some thing and the build will fail. I tend to forget pointing out the linker script...
  • This is an interative process until you have a successful build!
  • Then compare the build result vs the MX project. Is the text/data/bss section identical in size? If so there is a 99% chance you have an identical project migrated from MX to CDT. If not, diff the map-files!
• DEBUG: Generate debug configs and try the proejct.

That to me summarizes the workflow. This is complicated if you rely on additional tools to generate code like TouchGFX Designer. Then you may also need to re-consider how/where this tool generates files and how to best manage them in the new project...

Also people starting from example projects with linked resources cannot really follow this path. The linked resources are the obstacle which will making copying files impossible. But the linked resources can be resolved if the example is imported using the MCUFinder/CubeMX wizard in CubeIDE isntead of the normal Eclipse import frameworks. I hope that makes sense...

[msch]

Ok, I get the picture. A nuisance, but one only has to do it once (per project).

Aside from being able to change the MCU, are there any other advantages over just leaving a project as an MX project? And in a CDT project, what information does CubeIDE take from the MCU setting? In other words, if I change the MCU setting, what things will be automatically changed in the project?

[mattias norlander]

Advantages... Well since CubeMX does not manage the project you are free to modify any setting and add/remove any file without having to consider that MX may own some resources. On the other hand you lose MX GUIs and automated code generation completely. So in a nutshell you make the choice between "flexibility" vs "automation".

[mattias norlander]

"As for "CDT" projects - i's not clear what you mean by this."

When saying "CDT" projects, I refer to the native Eclipse/CDT project format.

Opposed to "STM32Cube" or "Empty" project which were once we originally created for CubeIDE. As things evolved we fixed some issues allowing our "build and debug" tools to work with CDT projects, which makes this project format a viable option.

Trying to explain the concepts you bring up I would look at it in a tree representation:

• CDT project
  • Managed projects
    • Internal builder (CDT GUIs generate command line options used to directly invoke gcc)
    • External builder (CDT GUIs generates a Makefile. Make invokes gcc)
  • Unmanaged project (Makefile project, makefile created & maintaned by the user!)

The choice between internal vs external builder is primarily based on which of the two builders that has the most traction in the Eclipse/CDT community. External build had (have?) more momentum when we introduced CubeIDE. TrueSTUDIO relied on Internal builder and we considered changing to external, but never got that far.

I hope that clarifies some parts.

[msch]

Ok. Could you address the second part of my question? If I change the MCU setting in a CDT project, what will happen? Is it just changing some of the flags that are passed to the toolchain? Anything else?

[msch]

Thank you, that's a good explanation.

[mattias norlander]

Changing MCU does two things:

• Change toolchain settings like mcpu, mfpu, mfloat-abi, and the correct selection of C libraries.
• Feeds the launch configuration with MCU specific information to allow the STM32 Cortex-M C/C++ Application launch type to be usable.

[ATymo.1]

You cannot just copy a project and open it in the same workspace. It seems that this conflict is related to the indexing of projects by name. And two identical names are not allowed.

But you can do it like this.

Method 1.

Import the aligned project into a new workspace

Method 2

1. Copy the project folder to a new location (file manager)

2. Rename the project to Stm32CubeIDE (for example, add its previous version to the name)

3. Import the copied project into Stm32CubeIDE (essentially with the old name)

Method 3.

Manually edit the project files ".project" and ".cproject". These are normal xml files.

In the ".project" file, the project name is contained in the tag

projectDescription->name

There are more tags containing the project name in the ".�?project" file. It is better to carefully drop them all through a file search.