STM32CubeMX Generate All Source Files

[nlippitt]

Scenario: I am using STM32CubeMX (v6.13.0) to generate the necessary project files for a default STM32U5A9J-DK project with ThreadX enabled.  The project files are copied into a docker container and built with cmake.  Building and debugging in the container works until I attempt to add the ThreadX middleware.  Outside of the container building and debugging with STM32CubeIde is not an issue.

Problem: The STM32CubeMX generated project files are not sufficient to compile a ThreadX program.  Undefined reference problems flood the output.

Debug:

1) I have tried combinations of the settings in STM32CubeMX including: "Generate Under Root," "Enable multi-threaded support," and "copy all used libraries into the project folder" to no avail.  My cmake program recursively adds all .h, .c, and .s/.S files as sources or include paths as appropriate in the project folder, so all generated files are always used.

2) I attempted to resolve the undefined issues by manually adding the source files missing from the firmware package STM32Cube_FW_U5_V1.7.0.  I pull down the repository from git during my container setup.  First, I included all files in the package.  This was unsuccessful and resulted in errors.  Next, I included only necessary files and directories, viewed the remaining dependencies, and repeated the process.  This was a painful and undesirable tactic, and did not solve the problem either.  A file that did not exist in the firmware package was referenced.  Because ThreadX functions outside of the container referencing the same firmware package, I do not understand how to reference all the required files and why the option to "copy all used libraries into the project folder" fails for this middleware.

Please send support on resolving this issue.  I am hoping I am unaware of the proper way to access the needed files.  I can send more information on specific errors as desired.

Note: FreeRTOS was previously used in a similar fashion with a STM32H7 uC in a docker container without issue due to all necessary files being generated.  However with the STM32U5 I must use LevelX and USB operations, so ThreadX is the natural choice and I do not want to run into the same missing files issues when I add the LevelX and USB middlewares to the project.  Thanks!

[STM_Thirty2]

I can verify the Cmake generation for that board is really messed up, we apologize for this.

However I did try instead to make a container using an STM32Cube IDE project based on your board and succeed with the following notes:

Issue 1 : Makefile contains hardcoded paths to the liner script

Solution 1: Update Paths in the Makefile

1. The Makefile located in Debug/Makefile uses hard-coded paths when referencing the linker script. Since these paths are specific to the host machine, they will fail in the container environment.
2. To fix this, update the linker script paths in the Makefile to use relative paths (../) instead of absolute paths. This ensures compatibility across different environments.

Solution 2: Simplify by Copying the Linker Script

1. A simpler alternative is to remove the path entirely and leave just the linker script name in the Makefile.
2. Then, copy the linker script file into the Debug folder so that the Makefile can easily locate it without needing a path reference. Note there are two instances of the path in the Makefile in the u5-test-3.elf u5-test-3.map section.

For example I copied the liner script into the debug folder and my path changed from:

/home/eddie/tmp/docker-test-3/u5-test-3/STM32U5A9NJHXQ_FLASH.ld

To

STM32U5A9NJHXQ_FLASH.ld

Issue 2 : arm-none-eabi-gcc flags

Since my dockerfile installs arm-none-eabi-gcc from whatever repo ubuntu gets it from, that mainline version does not really align with the version shipped with ST's software.

Solution 1: Include STM32CubeCLT

1. Download and copy STM32CubeCLT into your container and use the arm tools in there and reference that everywhere the build system call arm gcc.

Solution 2: Simply remove the flag

1.  I simply removed the flag, it is nothing more than a metric measuring readability, maintainability, and testability of functions.

I have attached my project and dockerfile with included changes. Im not sure what your complete project has but I simply added ThreadX to the board project,  you can edit the project in the zip file per your needs and rerun the docker build command, it will copy the project into the docker environment.

 docker build --no-cache -t stm32-container .