STM32CubeMX – physical folders and file grouping

[Zebi]

Hi

Maybe this is a regression.

The setting “Group Sources By Types” has no effect in the current version in an STM32CubeMX project. – Neither on existing files, nor on new files. New files first seem to be created ungrouped but they are grouped by type when the solution is opened next time.

Attachments:

You must be logged in to view attached files.

[Zebi]

Hi

I have the same problem.

I created a new project via the new method for STM32CubeMX projects and the is no way to create folders to structure my source code files.

In an older project created via the old method folders work.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

VisualGDB indeed does not have a separate menu command for creating physical folders. However, it will recognize the actual folders where the sources are located. E.g. you can try clicking Add->New Item, and appending “\subfolder” to the Location field. VisualGDB will automatically create subfolder, will place the new file there, and will show it in Solution Explorer.

We have rechecked the Group Sources by Types setting and it worked just fine – hid the Source files and Header files nodes as expected. Please try checking it on a newly created project without changing any other settings. If it works there, please try comparing the 2 projects to see if there is any other setting you could have changed that triggered this behavior. Please also make sure the project is saved after you change the setting. If you close Visual Studio without saving the solution/project, the setting will not be saved and VisualGDB will revert to the old behaviour next time you open the project.

[Zebi]

Hi

I have now re-created the solution and the issue is gone. The behaviour is now as you describe. Maybe I triggered the switch-over to allways grouped by my attempts to create a folder.

When re-creating the solution I stumbled upon another issue:

At the wizard stage where I select the debug method. There are 2 methods offered: “OpenOCD” and “OpenOCD (STM32H7R/S)”.

I assumed the latter to be a more specific method for my selected MCU and selected it. After downloading a package there is no way back. The first debug method “OpenOCD” is now in a defective state as shown in my screenshots. Is there any way to recover from this or do I also need to re-create the solution?

Thanks for your help

Attachments:

You must be logged in to view attached files.

[Zebi]

Hi

What is the recommended workflow to move code files between folders in a project? Drag and drop between folders seems to be not supported.

[support]

The OpenOCD error looks like some of the debug plugins got cached incorrectly. Restarting Visual Studio should solve it.

Drag-and-drop between folders should normally work, unless you are trying to move files generated by STM32CubeMX. These files are intentionally non-movable, because re-running STM32CubeMX would re-generate them under old paths, creating conflicts between the new and old versions. If you are 100% sure you will not need to do that, you can create a regular CMake-based project, move the STM32CubeMX-generated code into it, and then most usual editing functionality will work just fine.

 

[Zebi]

Thanks for the help.

Unfortunately drag and drop of files between folders really doesn’t work. I created a fresh project, created a folder and 3 files and for every file I try to drag the pointer stays in “forbidden” state. Unfortunately screenshots don’t show this. If it would help find a bug I could send you the project.

[support]

Hi,

You can try recording a quick video of the problem using Windows Game Bar, and sharing that. It should help see what is going on.

[Zebi]

It took some time but here is the recording:

https://drive.google.com/file/d/1XcBWJ8ljLi3UpgIVJ9RVnKZXpt8xTY8A/view?usp=sharing

[support]

Hi,

Thanks for confirming this and sorry for the confusion. Dragging files works for virtual folders, when the physical files remain in the original location and the only thing changed is the view in Solution Explorer.

Physically moving files to different folders cannot be directly done via Solution Explorer, and needs to be done manually (i.e. remove files from the project, move them via Explorer, and re-import them back either manually or via Import Folder Recursively command). The main reason for this limitation is to be consistent with the regular VC++ projects where moving files in Solution Explorer never changes their physical location. If VisualGDB implicitly moved files instead, it could easily introduce build errors (e.g. when using relative paths to headers).

[Zebi]

Hi

Thanks for the clarification.

Is there any “better practice” you would recommend for structuring complex projects with lots of classes and application parts if a folder structure is not the preferred way?

 

Thanks

[support]

Hi,

You can use the virtual folders in Solution Explorer (similar to regular VC++ projects) or CMake source groups (requires editing CMakeLists.txt files, but will work with any IDE that uses CMake).

That said, the STM32CubeMX-based projects have a somewhat rigid structure where many parts gets regenerated when you change settings in the STM32CubeMX tool, overwriting the changes that were outside the specially marked blocks. We do not recommend this workflow for complex projects with non-trivial structure. Instead, we would advise having 2 projects:

• A simple STM32CubeMX project that has all the relevant initialization/configuration code generated by the STM32 tools.
• The main CMake-based or MSBuild-based project with production code, that has snippets copied from the STM32CubeMX project.

 

[Zebi]

Thanks, I’ll look into ways to split the project up.

[Author]

Posts