Problem creating new TrueStudio project for STM32L053 (and I assume all STM32L0 parts) in STM32CubeMX v5.0.1

[Daniel Glasser]

I updated CubeMX to 5.0.1 today, then created a new project for the Nucleo-64-STM32L053 board. I'm using Atolic TrueStudio for STM32 v9.2.0 as the IDE and toolchain.

I set up the project for the board, selecting and configuring peripherals, along with FreeRTOS and USB device (virtual com port), then generated the code; I selected the "Advanced" option under "Application Structure" in the project settings. For this project, the firmware STM32Cube_FW_L0_V1.11.0 is being used.

My usual practice is to build the generated project before I start changing things. This revealed a number of problems right off:

• The generated project included the startup code directories for KEIL, IAR, and GCC under "Drivers\CMSIS\Device\ST\STM32L0xx\Source\Templates", (the "arm", "gcc", and "iar" directories), and under each of those were 20 chip-specific assembly files. In my projects for other devices made with earlier versions of STM32CubeMX (pre 5.0) only have the "gcc" directory (or nothing at all) under "Templates", and the actual startup file was in the top-level project directory. The builder attempts to assemble the KEIL versions of the .s files under the "arm" directory, and the gas assembler chokes on them. I excluded the "arm" and "iar" directories, along with the extra startup files for the L0 devices that I'm not targeting, and tried to build again.
• The next set of 551 errors detected are in "Drivers/CMSIS/Include/arm_math.h" because nothing is defining "ARM_MATH_CM0" in the generated project. I went into project properties, and added "ARM_MATH_CM0" to the symbol definitions in the "C/C++ Builder|Settings|Defined Symbols" pane, applied the change, and tried to build.
• The next 4 errors detected are in the file "Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_desc_template.c", which should not have been copied to the project, as the generated file "usbd_desc.c" is under "USB_DEVICE/App" along with the header file "usbd_desc.h". I excluded the template file from the build and tried again.
• The build gets quite a bit further with over 100 warnings, but then fails in the linker due to multiply defined symbols encountered because of the file "system_stm32l0xx.c" appearing in two places. I excluded the one from "Drivers/CMSIS/Devicee/ST/STM32L00x/Source/Templates", (actually, the entire "Templates" directory") and tried again...
• With this, the build succeeds

My impression is that this is a bug in the tool:

1. STM32CubeMX is copying files it doesn't need into the project directory and not excluding them from the build.
2. Something should be defining the "ARM_MATH_CM0" symbol for the project; if it's not supposed to be in a header file, then it needs to be added to the project file build settings.

Updates:

1. I missed one of the templates that must be excluded in the above for the build to succeed: "Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_msp_template.c"; again, this file should not have been copied from the firmware repo by STM32CubeMX.
2. This part doesn't have enough RAM to do what I need to do with FreeRTOS, so I pulled that from the configuration; it did not affect what was copied other than the FreeRTOS sources and header files (and the elimination of the generated free_rtos .c and .h files)

[Markus GIRDLAND]

Hello Daniel,

I tried to follow your steps as well as I could but I don't experience the same issues as you. I don't get any at all, in fact.

However, I didn't get all of these unnecessary files generated with my project which explains why I don't get the related errors. Could you send the .ioc file for the project? Perhaps I can get a better understanding of what's happening from that.

[Daniel Glasser_2]

Hello, Markus:

Here is an IOC file from another project that I just created at home for an STM32F401RET6 Nucleo-64; it has similar problems.

In this case, I selected the basic directory structure.

It still included the templates, didn't define "ARM_MATH_CM4", and a raft of other failures.

In order to have this one build, I had to:

• exclude all of the files under "Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates" from the build
• exclude all of the files under "Middlewares/Third_Party/FreeRTOS/Source/portable/MemMang" from the build except "heap_4.c"
• exclude all files with "template" at the end of the filename in "Drivers/STM32F4xx_HAL_Driver/Src" ("stm32f4xx_hal_msp_template.c", "stm32f4_hal_timebase_rtc_alarm_template.c", "stm32f4_hal_timebase_rtc_wakeup_template.c", "stm32f4_hal_timebase_tim_template.c") from the build.
• In build settings, define the symbols "ARM_MATH_CM4" and "__FPU_PRESENT=1U"

I'm not 100% sure it's correct, as I've not yet made it do anything except build.

[Markus GIRDLAND]

Thank you for the file.

It seems to be related to the CubeMX project generation. I'll see if I can get it to their team to look over.

[Daniel Glasser]

An new observation: Last night, I created a virtually identical project to the examples above, and the tool generated a working project (no extra files, no need to add anything in the build settings), so my impression is that there is some randomness that has been introduced in the project generation. If CubeMX wasn't written in Java, I'd say it was an uninitialized variable. I'd have the tool team look at where the decisions are made for which files get copied.

[Mitja Jež]

Same issue confirmed from me. New project with CubeMX 5.1.0 generated project with all files that I lately removed from build.

Even before I get successful build i renamed that .ioc to get new project, that was generated properly.