Implementation `*.c-files` not being copied correctly in STM32CubeMX - missing from .pdsc?

[K1ngjulien]

Hi!

Problem

After finally figuring out how to get the cmsis-dsp package when using STM32CubeMX (manually downloading and installing the .pack for cmsis core and cmsis-dsp from https://www.keil.arm.com/packs/ ,they used to be avalable by default a few years back) i've run into another roadblock when trying to use it.

After getting the packages installed and selected in configurator, i enabled them, clicked "generate code" and tried to compile, with the following result:

...
[  2%] Building C object CMakeFiles/flugdatenlogger.elf.dir/Middlewares/Third_Party/ARM_CMSIS/Source/BasicMathFunctions/BasicMathFunctionsF16.c.obj
[...]/flugdatenlogger/Middlewares/Third_Party/ARM_CMSIS/Source/BasicMathFunctions/BasicMathFunctions.c:29:10: fatal error: arm_abs_f32.c: No such file or directory
   29 | #include "arm_abs_f32.c"
      |          ^~~~~~~~~~~~~~~
compilation terminated.
[...]/flugdatenlogger/Middlewares/Third_Party/ARM_CMSIS/Source/BasicMathFunctions/BasicMathFunctionsF16.c:29:10: fatal error: arm_abs_f16.c: No such file or directory
   29 | #include "arm_abs_f16.c"
      |          ^~~~~~~~~~~~~~~
...

after some investigation, I noticed that the implementation files arm_abs_f32.c, arm_abs_f16.c, etc. were not being copied into my project directory:

Only the "root" files, which include the implementation .c files are copied.

I checked the directory where STM32CubeMX installs its packages, but to my surprise, the files where there:

Out of curiosity, I then added one of those implementation files to the ARM.CMSIS-DSP.pdsc file

after restarting CubeMX (probably required to reload the package description from disk) and clicking "Generate Code" the file appeared!

Question

Now to my actual question(s).

Are the implementation .c files missing from the .pdsc file on purpose? Seems to me like they should be in there

https://github.com/ARM-software/CMSIS-DSP/blob/647b755ad80d53ecca56a555508084663f97c0eb/ARM.CMSIS-DSP.pdsc#L66

If not, would it be possible for you to add all the implementation ".c" files to the package description, so that they will be copied correctly in future versions?

Alternatively, could this be an issue with CubeMX not following the spec for package descriptions correctly?

Not sure if here's the correct place to report this, but i figured ST would take forever to respond :D

Thanks in advance! Cheers, K1ngjulien

Versions:

CMSIS-Core: 6.0.0 CMSIS-DSP: 1.15.0 STM32CubeMX: 6.10.0

[christophe0606]

@K1ngjulien I don't have problems with another IDE.

The implementations like arm_abs_f32.c are not directly listed in the .pdsc. Instead, for legacy reasons, there is a BasicMathFunctions.c listed in the .pdsc and this file includes arm_abs_f32.c.

In my IDE, I only see the BasicMathFunctions.c.

But, after building, I can list the files included by BasicMathFunctions.c and my IDE is displaying arm_abs_f32.c.

It has been done like that in CMSIS-DSP for a very long time.

I have just looked at the .pdsc spec and it is not clear about what should be the behavior of the IDE.

But, as I said : it has been like that forever in CMSIS-DSP and was working with STM32 IDEs so I am not sure the problem is related to this.

I agree that it may be cleaner to include the .c in the pdsc and perhaps it is a rework that will have to be done at some point. But compilation is also much faster as it is done today with those includes instead of compiling the hundreds of source files in CMSIS-DSP separately.

[christophe0606]

@K1ngjulien I've discussed with people involved in the definition of pdsc and pack standard. It looks like the problem may be with the STM32CubeMX.

Also the files from the pack should not be copied into the project. They should be referenced from the project directly. So it may explain the issue : the IDE is not copying the arm_abs_f32.c but this file should not have to be copied.

[jkrech]

@K1ngjulien just for me to follow the steps correctly ... You launch STM32CubeMX, create a new project for a board/device and then generate code for CubeIDE ? What are the settings in "Code Generator" section you are using? "Copy only the necessary library files" or "Add necessary library files as references in the toolchain project configuration file"

I think the latter will prevent STM32CubeMX from attempting to copy files into your workspace and this way you should be able to avoid missing files.

in .project I see:

        <link>
            <name>Middlewares/CMSIS-DSP/CMSIS/DSP/Source/BasicMathFunctions.c</name>
            <type>1</type>
            <locationURI>PARENT-3-PROJECT_LOC/Users/jkrech/STM32Cube/Repository/Packs/ARM/CMSIS-DSP/1.14.4/Source/BasicMathFunctions/BasicMathFunctions.c</locationURI>
        </link>

Note that if a module is listed as a source file of a component in the pdsc file it will trigger the invocation of the compiler with that file. Since here some c modules are looped in via #include they must not be build as individual modules. Unfortunately STM32CubeMX makes the assumption that the list of source files to be compiled also represents the list of modules that need to be copied if they should reside in project folder. This is not covered by the Open-CMSIS-Pack specification as only files with the config attribute represent configuration files that are application specific and user editable. All other files are "read-only" and should only be referenced.

BTW: For installing packs in STM32CubeMX: Open "Help" menu and select "Manage embedded software packages" At the bottom either click on "From Local ..." if you have that pack downloaded already or "From Url ..." use: https://www.keil.com/pack/ARM.CMSIS-DSP.pdsc

[ReinhardKeil]

@iomint it seems to be a problem in the way CubeMX handles #include files. Whereas *.h files are copied, files with extension *.c seem not to be copied.

[iomint]

I will have a look and discuss it with my colleagues in charge of STM32CubeMX

[K1ngjulien]

just for me to follow the steps correctly ... You launch STM32CubeMX, create a new project for a board/device and then generate code for CubeIDE ? What are the settings in "Code Generator" section you are using?

Yes, i was using "copy only the necessary library files". With STM32CubeIDE, I seems to be working when using the library reference.

Unfortunately I'm using CLion, and the generated CMakeLists is now missing the all source files, including HAL...

home/julian/.local/share/JetBrains/Toolbox/apps/clion/bin/cmake/linux/x64/bin/cmake --build /home/julian/code/dsp-test/cmake-build-debug --target dsp-test.elf -j 6
[8/8] Linking C executable dsp-test.elf
FAILED: dsp-test.elf 
: && /usr/bin/arm-none-eabi-gcc -g -Wl,-gc-sections,--print-memory-usage,-Map=/home/julian/code/dsp-test/cmake-build-debug/dsp-test.map -mcpu=cortex-m4 -mthumb -mthumb-interwork -T /home/julian/code/dsp-test/STM32F411VETX_FLASH.ld CMakeFiles/dsp-test.elf.dir/Core/Src/main.c.obj CMakeFiles/dsp-test.elf.dir/Core/Src/stm32f4xx_hal_msp.c.obj CMakeFiles/dsp-test.elf.dir/Core/Src/stm32f4xx_it.c.obj CMakeFiles/dsp-test.elf.dir/Core/Src/syscalls.c.obj CMakeFiles/dsp-test.elf.dir/Core/Src/sysmem.c.obj CMakeFiles/dsp-test.elf.dir/Core/Src/system_stm32f4xx.c.obj CMakeFiles/dsp-test.elf.dir/Core/Startup/startup_stm32f411vetx.s.obj -o dsp-test.elf   && cd /home/julian/code/dsp-test/cmake-build-debug && arm-none-eabi-objcopy -Oihex /home/julian/code/dsp-test/cmake-build-debug/dsp-test.elf /home/julian/code/dsp-test/cmake-build-debug/dsp-test.hex && arm-none-eabi-objcopy -Obinary /home/julian/code/dsp-test/cmake-build-debug/dsp-test.elf /home/julian/code/dsp-test/cmake-build-debug/dsp-test.bin
/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: warning: dsp-test.elf has a LOAD segment with RWX permissions
/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: CMakeFiles/dsp-test.elf.dir/Core/Src/main.c.obj: in function `SystemClock_Config':
/home/julian/code/dsp-test/Core/Src/main.c:124:(.text.SystemClock_Config+0x56): undefined reference to `HAL_RCC_OscConfig'
/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: /home/julian/code/dsp-test/Core/Src/main.c:138:(.text.SystemClock_Config+0x6c): undefined reference to `HAL_RCC_ClockConfig'
/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: CMakeFiles/dsp-test.elf.dir/Core/Src/main.c.obj: in function `main':
/home/julian/code/dsp-test/Core/Src/main.c:73:(.text.main+0x2): undefined reference to `HAL_Init'
/usr/lib/gcc/arm-none-eabi/13.2.0/../../../../arm-none-eabi/bin/ld: CMakeFiles/dsp-test.elf.dir/Core/Src/stm32f4xx_it.c.obj: in function `SysTick_Handler':
/home/julian/code/dsp-test/Core/Src/stm32f4xx_it.c:188:(.text.SysTick_Handler+0x2): undefined reference to `HAL_IncTick'
Memory region         Used Size  Region Size  %age Used
             RAM:        1976 B       128 KB      1.51%
           FLASH:        1268 B       512 KB      0.24%
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

but i only got that far after deleting .cproject/.mxproject/.project because its seems to not regenerate the CMakeLists at all otherwhise... at least its seems to now find the headers stored in ~/STM32Cube

Looks to me like a definite problem with STM32CubeMX so this is probably the wrong place for this discussion

[christophe0606]

I close it since we have concluded it is not directly related to CMSIS-DSP.