CubeAI generates wrong relative paths in CMake projects

[devjalx]

Hi all,

this issue is related to: https://community.st.com/t5/stm32cubemx-mcus/cmake-project-generation-with-cubemx-cubeai-fail/m-p/770680/highlight/true#M31054. , where it was solved by updating from STM32CubeMX V6.12.0 to STM32CubeMX V6.13.0. However, I have STM32CubeMX V6.16.1, so the error might have reappeared.

Background: I try two write code for an STM32N6 and use a CMake project for this. For the setup, I used the following tutorial: https://community.st.com/t5/stm32-mcus/how-to-debug-the-stm32n6-using-vs-code/ta-p/833499 and I can compile + flash the code and get a blinking LED, so the CMake project itself is working correctly.

However, when I export a neural network to the Application using CubeAI, CubeMX generates wrong relative paths in Appli/mx-generate.cmake. More specifically, all paths related to CubeAI have one "../" more than needed. Example: 

----------------

set(ST_Src
${CMAKE_CURRENT_SOURCE_DIR}/../../Middlewares/ST/AI/Npu/ll_aton/ll_aton_osal_threadx.c
----------------

Correct would be: 

----------------

set(ST_Src
${CMAKE_CURRENT_SOURCE_DIR}/../Middlewares/ST/AI/Npu/ll_aton/ll_aton_osal_threadx.c
.....

----------------

As a result, when gcc compiles the code, it throws multiple errors like:

----------------

[build] CMake Error at mx-generated.cmake:98 (target_sources):
[build] Cannot find source file:
[build]
[build] ...../Middlewares/ST/AI/Npu/ll_aton/ll_aton_osal_threadx.c

----------------

I appended the .ioc that generated the code.

Do you have an idea what is the cause of this error and how it can be avoided?

Best,

devjalx

[Mahmoud Ben Romdhane]

Hello @devjalx 

Let me thank you for posting.

I am currently checking this behavior, and I will get back to you ASAP.

Thanks

Mahmoud

[devjalx]

Hi,

just, wanted to follow up. I now also tested this with a fresh installation on a different PC with a different operating system. I also tried to downgrade CUBE-AI to 10.1.0. Same behavior in all configurations.

I also tested a "standard" STM32H735 with a single Arm-Cortex M7, there everything compiles. So it seams, there are some problems in Cube-AI with the STM32N6. Most likely, it messes up folder structures as it has to generate code for the FSBL and Application.

To summarize, the problem occurs on MacOS Silicon and Ubuntu 24.04, under CUBE-AI 10.2.0 and CUBE-AI 10.1.0 only for STM32N6.

[devjalx]

Hi,

there is more stuff broken. It not only messes up the relative paths, it also forgets to include the HAL/LL drivers in the compilation, i.e., even if you fix all broken paths, you get many linker errors of the form:

undefined reference to `HAL_CACHEAXI_Init', 

undefined reference to `HAL_GPIO_WritePin'

etc. depending on what you have configured.

Here is a workaround to make the code compile:

1. Generate the code using CUBE-MX with CUBE-AI disabled.

2. In Appli/mx-generated.cmake, locate the line # STM32 HAL/LL Drivers. Below it, copy the part: set(STM32_Drivers_Src ....

3. Generate the code using CUBE-MX with CUBE-AI enabled.

4. In Appli/mx-generated.cmake, replace all occurences of ../../ with ../.

5. In Appli/mx-generated.cmake, locate the line # STM32 HAL/LL Drivers and replace the part set(STM32_Drivers_Src ... with the content copied in step 2. You should notice that this part now includes much more source files in the compilation.

[Mahmoud Ben Romdhane]

Hello @devjalx 

Let me thank you for bringing the issue (CubeMx generates wrong relative paths in CMake projects) to our attention.

The issue has been escalated internally to the dedicated team for further investigation and resolution. (Ticket 226536). This is an internal tracking number and is not accessible or usable by customers.)

While correcting the added ./../ in mx-generated.cmake, I did not get linker error.

Thanks.

Mahmoud

[Ropi]

Hey, since the ticket you mentioned is internal, we can't see its status. Can you please give us an update on it? Has the bug been found already? What's the release schedule for ST software components? In short: when can we expect a fix?