STM32Cube: Generate code from command line with no GUI

Avi Shukron · ‎2018-06-14

Posted on June 14, 2018 at 17:59

Hi!

I have a project based on STM32. The project can be configured to run on several STM32 boards.

Each board configuration is represented by the `.ioc` file created by CubeMX.

I want to have a CI (Continuous Integration) setup that will compile the project for all supported boards.

In order to do this I created a Docker image with Java, STM32CubeMX and all the necessary toolchain.

Then I wrote a Cube command line script that generates the code given a `.ioc` file as an input.

I invoke this script as part of a Makefile using a line similar to this:

java -jar STM32CubeMX -q my_script

Since I passed the `-q` flag, I expected that no GUI will be presented.

The docker container crashes executing this line, since it does not have a display capabilities requested by CubeMX, even if it is not going to display anything.

I tried doing this on an actual machine without docker, but then sometimes I would get a popup window during the generation process that requires user intervention.

Such window might pop when you enable FreeRTOS and select SysTick as the HAL timebase source:

This is a problem since the generation process is halted until the user presses a button, which is unacceptable for automated CI environment.

Is there a way to use Cube as a *true* CLI? I would rather it failed when encounter any problem, instead of waiting for user input.

Is such thing possible?

#stm32cubemx. #stme32-cube

Asaf Kahlon · ‎2018-06-14

Posted on June 14, 2018 at 18:59

OMG this is the exact same problem I'm currently facing!!

I think it's trival to have a cli-only capabilities for the STM32CubeMX for people who like to have an automation process with this tool.

Vitaliy Chernobay · ‎2018-06-14

Posted on June 14, 2018 at 21:18

it will probably be useful

https://community.st.com/0D50X00009XkXi7SAF

Pavel A. · ‎2018-06-14

Posted on June 14, 2018 at 23:39

IMHO what you want is abuse of CI. CubeMX should not be used this way. You change the CubeMX project (.ioc) only when something changes in hardware settings. These changes should be validated manually, sometimes manual changes and merges in the generated code are needed too. Once you do this manually for each needed IDE/toolkit, you check all generated projects into version control and then focus on writing the application code (which should be decoupled from the stuff generated by CubeMX.) When the app code changes, CI does its magic. But CubeMX is no longer involved.

-- pa

Asaf Kahlon · ‎2018-06-15

Posted on June 15, 2018 at 07:04

I don't agree that 'CubeMX should not be used this way' - why not? Just because it was built that way? It doesn't mean that's true.

I want to make sure my code always compiles, and for that I need to have the generated outputs from Cube. I don't believe in committing generated code to the repository, and I don't think that it's so hard to have a command to just generate the code from the current configuration. Many standard tools have support for working with CLI.

I agree with you that the process of changing the CubeMX project has to be done manually, but after the manual configuration is done, nothing should be on my way when I want to create an automation routine. The configuration file should be enough for generating the code. I can agree that warnings should be popped-up, but a flag for generating anyway should be supported too...

Avi Shukron · ‎2018-06-17

Posted on June 17, 2018 at 13:51

Commiting auto-generated code is a bad practice, as you will end up with multiple sources of truth about your hardware configuration.

The ioc file contains *all* the necessary information to generate the code.

Given a CubeMX version and an ioc file, the generated code is guaranteed to be the same, so that are the only variables that should be under version control (aside from the application of course)

Pavel A. · ‎2018-06-17

Posted on June 17, 2018 at 14:13

>

The ioc file contains *all* the necessary information to generate the code.

?? The .ioc contains only information to generate a (standard) part of initialization code.

Even to blink a LED you need to add some code to the cube generated source. Once you add that, you want to check it in.

-- pa

Asaf Kahlon · ‎2018-06-17

Posted on June 17, 2018 at 19:06

I completely agree that the .ioc file is not the whole code, but it doesn't have to change something regarding the CI process. If I want to blink a LED, I will generate the 'base' code from the .ioc file and write my own code to play with the LED. I still should be able to build automation process around this two phases, and currently the CubeMX blocks me from doing the first part (and hence blocks me to implement CI at all, unless I commit the generated code to my repo, which is a bad habit).

themole · ‎2018-08-22

I have a very similar problem. As part of my CI process, I want to generate the documentation of a CubeMX project. Therefore, I installed CubeMX on my Jenkins host on command line, which worked like a charm, but when it comes to using CubeMX on command line, I always get the following error:

Exception in thread "main" java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
        at java.awt.Window.<init>(Window.java:536)
        at java.awt.Frame.<init>(Frame.java:420)
        at javax.swing.JFrame.<init>(JFrame.java:233)
        at com.st.microxplorer.maingui.MainFrame.<init>(MainFrame.java:53)
        at com.st.microxplorer.maingui.MicroXplorer.run(MicroXplorer.java:165)
        at com.st.microxplorer.maingui.STM32CubeMX.run(STM32CubeMX.java:24)
        at com.st.microxplorer.maingui.STM32CubeMX.main(STM32CubeMX.java:37)

This happens for the easiest possible script with only the exit command in.

Is there any possibility working around this problem?

themole · ‎2018-08-22

I SOLVED my problem with a workaround: I used xvfb to create a virtual X11 Display before executing CubeMX. This script helps to get it into background: https://gist.github.com/jterrace/2911875

Unfortunately, generate the PDF doc is not part of the scriptable commands... :(