Running STM32CubeMX without GUI

[ANath.1]

Hi All,
I am trying to setup a build pipeline for the STM32 platform to be able to compile projects in an automated fashion. So far, I have an .ioc file which I use the to generate the project using the STM32CubeMX commands which are invoked via the script in the cli mode. The flow works on an Ubuntu machine which supports GUI. However, when I try to containerize the flow into a docker container, the build breaks as the STM32CubeMX tries to render a progress bar for the Loading IOC step followed by a Rendering UI progress bar. It is not possible to load display components on the docker and hence STM32CubeMX code generation fails. Is there any way to launch STM32CubeMX in a headless non-gui mode so that we can run this on headless machines?

This is the UI that pops up.
The following is the contents of my script file

config load <filename>.ioc
project name app
project toolchain STM32CubeIDE
project path <path>
SetCopyLibrary copy all
SetStructure Advanced
project generate
exit

 Command to invoke STM32CubeMX:

java -jar <path_to_CubeMX>/STM32CubeMX -q <scriptfile>

Thanks,

Abhijit Nathwani

[Ghofrane GSOURI]

Hello @ANath.1 

Thanks a lot for having reported.

Issue has been raised to our dev team in order to fix the issue.

Internal ticket number:   183448 (This is an internal tracking number and is not accessible or usable by customers).

I will keep you posted with updates

THX

Ghofrane

[ANath.1]

Hi @Ghofrane GSOURI 
Thank you for the response. Request you to kindly keep updating the thread here with updates to the issue.

Thanks,

Abhijit Nathwani

[BarryWhit]

@ANath.1 , please see discussion in Project generation from command line, headless for a possible solution.

[andrew_parlane]

Hi Ghofrane,

I'd like to +1 this request. Having tools that can run sensibly in a headless environment is a very common requirement in a professional environment these days. The STM32 tools are almost there, and are much better than some others I have used.

Thanks,

Andrew

[ANath.1]

Hi @BarryWhit ,
The current workaround I implemented is using xvfb display as discussed in the thread. However, in a *headless* build tool, it should not be required, as documented in the user guide. So this is a definite bug that needs fixing.

Thanks,

Abhijit Nathwani

[BarryWhit]

I guess what you're saying is technically correct. I think what ST actually means by headless is more like "batch-mode"/"non-interactive"/scriptable, no GUI interaction required. But by all means, you guys get them to fix it if you can. There's also the issue where if something goes wrong during batch-mode generation, you get a GUI message box and user interaction is required instead of cube exiting with an error code - which is not cool (and andrew said as much in the other thread).

[Pavel A.]

Already several times people ask for scriptable CubeMX code generation for CI. I really cannot understand why they think they *need* this, sorry. It looks rather like a X/Y issue. Maybe what they actually need is configuring the projects to *link* to Cube libraries located somewhere else, rather than *copying* the static library files into their projects. (looking at the statement "SetCopyLibrary copy all" in the OP). 

In my experience, generation or re-generation of a project in Cube always requires a review and build validation by a human. This makes all generated files "precious" and justifies keeping them in version control. Especially files that contain "user code" sections. The "static" Cube library files with this approach are not copied into the project and not included into the project version control repo at all - they are in a separate "library" repo or module (or directly pulled from the official ST github repo).

So there's no real need to involve the CubeMX and its databases into CI automation. The future removal of the CubeMX part from CubeIDE will help to put the latter in a container.

The only reason to need (*) CubeMX generation in CI pipeline is IMHO only when you develop a CubeMX add-on or work for ST and test the CubeMX itself.

(*) difference between need and want

[andrew_parlane]

---

@Pavel A. wrote:

I really cannot understand why they think they *need* this, sorry. It looks rather like a X/Y issue.

---

We don't need it, but It's not an X/Y issue. It's just a nice to have that's a very common feature and fits into a sensible build flow, allowing  continuous integration, automatic builds, etc... We can work around this not technically being supported, but it's being asked for a lot because it's a pretty basic feature these days.

---

@Pavel A. wrote:

Maybe what they actually need is configuring the projects to *link* to Cube libraries located somewhere else, rather than *copying* the static library files into their projects. (looking at the statement "SetCopyLibrary copy all" in the OP). 

---

That would work for some cases but not all.

1. When there are bugs / missing features you sometimes want to patch the provided code.
2. When you actually want auto-generated code, rather than just copied files. For example how main() is auto-generated to initialise your peripherals. Or those same peripheral initialisation functions.

---

@Pavel A. wrote:

In my experience, generation or re-generation of a project in Cube always requires a review and build validation by a human. This makes all generated files "precious" and justifies keeping them in version control. Especially files that contain "user code" sections. The "static" Cube library files with this approach are not copied into the project and not included into the project version control repo at all - they are in a separate "library" repo or module (or directly pulled from the official ST github repo).

---

I would disagree. Generation should be a repeatable process. If I re-generate the same project without any changes to the configuration file / script the output should be consistent. Files with "user code" in them would clearly need to be checked in, but that's something I've (and I assume many others who are asking for this) have explicitly avoided so we don't have to check these files in.

The problem with checking these auto-generated files in are:

• They often don't match coding standards, while not a problem in it's own right tools may have to be configured to avoid automatic checks on these files when checking them in.
• A minor change to a configuration file can cause a handful of unrelated changes in auto-generated files which make the code review process harder, and clutter up the commit. For example I added a new peripheral which then got initialised in main(), this caused two other initialisations to swap locations.
• Text editors that automatically format code / remove whitespace / line endings could make accidental changes to these files which you then have to constantly revert so they don't end up cluttering up your git status.
• If you modify the code in anyway (bug fix, feature addition), you have to re-apply the fix manually after every regeneration. By not checking in those changes you can add a patch to your generation script to do this automatically. If you update the FW package you may have to update the patch, but simply regenerating the project (as long as you use your script) will always work.

These are all problems I've had over the years working with various different tools, and this has led me and the company I work for to have a policy to not check in auto-generated code where possible. Other companies may have different policies, and I'm not saying they are wrong, there's no perfect solution here. I would however like the option to do this without jumping through a bunch of hoops.

I would also like to clarify that the STM32 tools are been pretty decent quality compared to some tools I've worked with. This feature is so far my only real complaint.

Andrew

[BarryWhit]

> They often don't match coding standards

but the style guide should executable and automated. The pretty printer can applied automatically when checking in, with a git hook.

> A minor change to a configuration file can cause a handful of unrelated changes in auto-generated files which make the code review process harder,

I think this is a good point. We use code-generation to reduce the cognitive overhead of boilerplate. Putting the boilerplate in commits, arguably, runs counter to that. OTOH, there's also a strong trend of vendoring every dependency you can, to insulate your build from the whims of some 12-year old who wrote a nodejs module in 2014, which you didn't even know was a transitive dependency of your project way way down in there. So there's

also an argument for keeping everything you need to reproduce your build, if github has a meltdown tomorrow for example. or in 10 years if ST changes the generator in incompatible ways, and the version you use now is no longer available for download, but your biggest customer is paying you $$$ to make a change. etc'.

> Text editors that automatically format code / remove whitespace / line endings

can be configured not to do so.

> so they don't end up cluttering up your git status.

Just FYI, git (via .gitoptions) can be configured to ignore whitespace changes IIRC, and also to control how crlf it managed in working dir vs. commits (windows/linux convention).

> If you modify the code in anyway (bug fix, feature addition), you have to re-apply the fix manually after every regeneration. By not checking in those changes you can add a patch to your generation script to do this automatically.

And if you can automate the latter case, you can also automate the former. Whenever you regenerate after a change, you also recompile and run tests. Just put the patch-check/apply in your makefile. Or again, in a git hook.

Not to mention, you could customize the templates CubeMX uses to generate the code in the first place.

So yeah, everything can be worked around, Like you said, What I don't understand is what about the current (admittedly wonky) situation is preventing you from doing any of the things you described. It's just the wonkiness itself that's not great right?

As an aside, are you aware that ST has a project going centered around providing a parallel development flow using VSCode? I'm not sure how the code generation is worked in (Update: the user uses the CubeMX GUI to generate CMake projects which VS Code/the extension can work with), but you should have a look - There's a thread about it around here somewhere.