2025-03-26 12:25 PM - last edited on 2025-03-26 1:19 PM by Andrew Neil
Using "Firmware Relative Path" and generate code with references f STM32CubeIDE will mix relative and absolute paths in generated project files
STM32CubeMX 6.14.0 on Windows 11.
1. Create a directory and unzip en.stm32cubeh5-v1-5-0.zip there
1. Create a minimalistic new project in STM32CubeMX for STM32H5.
2. In tab Project Manager, tab Project:
2.1 Set Project Location to the created directory and set the name of your project
2.2 Set Toolchain / IDE to STM32CubeIDE
2.3 Uncheck Use Default Firmware Location
2.4 Use the browse button and select STM32Cube_FW_H5_V1.5.0 in the directory.
3. In tab Project Manager, tab Code generator: choose option Add necessary library files as reference in the toolchain project configuration file
4. Save the project and generate the code.
Note that the path is correctly stored as a relative path in the .ioc-file with the key ProjectManager.CustomerFirmwarePackage
Bugs
Despite that the actual relative path from Toolchain Folder Location is ..\STM32Cube_FW_H5_V1.5.0, the UI always show the resolved absolute path. This is confusing as it is hard to understand if you have selected the correct path that will also survive if the whole created directory is committed to VCS.
This should really be changed to show a relative path to toolchain folder and the labels should clarify that the toolchain folder is the base.
In the generated STM32CubeIDE project, the .project will use expected relative paths, e.g.
<linkedResources>
<link>
<name>Drivers/STM32H5xx_HAL_Driver/stm32h5xx_hal.c</name>
<type>1</type>
<locationURI>PARENT-1-PROJECT_LOC/STM32Cube_FW_H5_V1.5.0/Drivers/STM32H5xx_HAL_Driver/Src/stm32h5xx_hal.c</locationURI>
</link>
But in .cproject, the include paths will be recorded as absolute paths which means that the project cannot be shared with another developer unless s/he puts the project in the exact same location, e.g.
<option id="com.st.stm32cube.ide.mcu.gnu.managedbuild.option.defaults.1522202762" name="Defaults" superClass="com.st.stm32cube.ide.mcu.gnu.managedbuild.option.defaults" value="com.st.stm32cube.ide.common.services.build.inputs.revA.1.0.6 || Debug || true || Executable || com.st.stm32cube.ide.mcu.gnu.managedbuild.option.toolchain.value.workspace || STM32H563RITx || 0 || 0 || arm-none-eabi- || ${gnu_tools_for_stm32_compiler_path} || ../Core/Inc | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/STM32H5xx_HAL_Driver/Inc | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/STM32H5xx_HAL_Driver/Inc/Legacy | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/CMSIS/Device/ST/STM32H5xx/Include | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/CMSIS/Include || || || USE_HAL_DRIVER | STM32H563xx || || Drivers | Core/Startup | Core || || || ${workspace_loc:/${ProjName}/STM32H563RITX_FLASH.ld} || true || NonSecure || || secure_nsclib.o || || None || || || " valueType="string"/>
Absolut paths also end up in .mxproject but using \ as path separator instead of /. I am not sure what this file is actually used for.
My intended use case was to have developers share both the actual product projects and a common controlled copy of ST HAL and middleware code, without requiring everyone to have the ST code at the exact same place in their local filesystem - we all know that such a requirement doesn't scale past 2 developers in the same room.
But with the bugs above, the option Add necessary library files as reference in the toolchain project configuration file cannot be used for that.
Best regards, Jesper
2025-03-26 12:38 PM - edited 2025-03-26 12:38 PM
Forum threads that somewhat relate to this issue:
STM32CubeMX Feature request: possibility to specify relative paths or our own paths. 2017-09-01
STM32CubeIDE uses relative paths when linking to firmware at an absolute path 2020-09-22
STM32CubeIDE project setup for collaboration with version control 2020-08-30
Custom packs path in IOC files 2024-05-15
2025-03-26 4:17 PM
> the UI always show the resolved absolute path. This is confusing as it is hard to understand if you have selected the correct path that will also survive if the whole created directory is committed to VCS.
So users are encouraged to choose locations that are OK for their build environments and VCS. This is possible, not just for two folks in a room.
Think "convention over configuration".
> Absolut paths also end up in .mxproject but using \ as path separator instead of /. I am not sure what this file is actually used for.
We don't save .mxproject files in VCS. Haven't seen any problem.
> But with the bugs above, the option Add necessary library files as reference in the toolchain project configuration file cannot be used for that.
Again, convention over configuration plus some cheap tricks (symbolic links exist on Windows too) - and this works.
'Do not panic!"