STM32CubeMX generate incomplete code for an LL based STM32L1 project

[Vasile Guta_Ciucur]

Posted on September 09, 2017 at 06:39

Update:

 As the below error appeared when I tried to make a Low Layer project for Nucleo L152RE board using STM32CubeMX in generating a code for a Makefile project, and, it was solved by an update to both STM32CubeMX and LL driver, the generated code remains unusable so, I chose a more appropriate title.

Original topic:

- undefined reference to `LL_RCC_GetSystemClocksFreq'

This function is referenced inside LL_I2C_Init function. I am using the last version of STM32CubeMX and I'm writing code for Nucleo L152RE board using Low Layer drivers.

I generated code for using the I2C1 peripheral, and I did a compilation without adding my own code. And it trows the error specified in the title at linker time. I also use the last version of ARM gcc compiler from the gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 archive under Linux Fedora 26. 

I attached the project archive.

#stm32cubemx #i2c #timer #incomplete-code #undeleted-temporary-files #missing-files #beta-quality #nucleo-l152re #linker-error

[Vasile Guta_Ciucur]

Posted on October 08, 2017 at 03:32

When you create an I2C project, the omitting of stm32l1xx_ll_rcc.c is still a current problem in 4.22.1 :

Well, I loaded a similar project in CubeMX and activated the I2C peripheral, specified the LL driver, saved the project as a new project and generated the code. The required .c file was omitted (but not his header).

[Amel NASRI]

Posted on October 11, 2017 at 15:21

Hi

Guta_Ciucur.Vasile

‌,

Thanks for the follow of this thread and all the entries you shared, that should help us to fix the reported issues.

These are the resultsof the quick analysis I made:

1. based on the .ioc file you shared in the packagemk_ll_pcf8583_lcd.tar.gz, I confirm the error you reported using Keil as toolchain.
2. I agree with you that a call toLL_FLASH_Enable64bitAccess has to be added as the Flash latency cannot be updated (with the call ofLL_FLASH_SetLatency in SystemClock_Config) unless the ACC64 is set.

These 2 bugs are reported internally.

For the 3rd case related to TIM, I suggest that yo add the code into a 'User code' section to avoid its overwriting.

-Amel

[Vasile Guta_Ciucur]

Posted on October 12, 2017 at 04:18

Thank you Amel, much appreciated!

As for TIM, please consider that you deal with a beginner that doesn't know yet what is needed for a TIM to start working and anyway, I understand that that is the minimum code (at least. for exactly that reason) that must be generated by the CubeMX. Then it comes the user addition. In fact that was what I wanted to underline: the CubeMX doesn't do yet a complete job regarding generating LL based code. But I know it is a matter of time.

Thank you again!

[Vasile Guta_Ciucur]

Posted on October 24, 2017 at 20:22

Dear Amel,

Is the new version, 4.23.0 supposed to solve the bugs I reported? Thank you!

[Vasile Guta_Ciucur]

Posted on October 26, 2017 at 16:08

Nope, the 4.23.0 version does not address those bugs. More, after migrating an existing project, renaming it, saving and generating the code, now in the Src folder are temporary files remained undeleted. I would say that you guys released a beta product without marking it as such...

[Vasile Guta_Ciucur]

Posted on November 12, 2017 at 09:31

The version 4.23 generate a broken Makefile for a new project - includes duplicate source files like bellow:

######################################
# source
######################################
# C sources
C_SOURCES = \
Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_ll_exti.c \
Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_ll_pwr.c \
Src/system_stm32l1xx.c \
Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_ll_utils.c \
Src/main.c \
Src/main.c \
Src/stm32l1xx_it.c \
Src/stm32l1xx_it.c \
Drivers/STM32L1xx_HAL_Driver/Src/stm32l1xx_ll_gpio.c 
�?�?�?�?�?�?�?�?�?�?�?�?�?�?

And specifies the main.c file in the path section:

#######################################
# paths
#######################################
# source path
SOURCES_DIR = \
Drivers/CMSIS \
Drivers \
Drivers/STM32L1xx_HAL_Driver \
Application/User/Src \
Application/User \
Application/User/Src/main.c \
Application/MAKEFILE \
Application/User/Src/stm32l1xx_it.c \
Application
�?�?�?�?�?�?�?�?�?�?�?�?�?�?

It doesn't affect me, as I copy a similar Makefile from the previous version (that had a functional Makefile), but this

prevents me from presenting STM32CubeMX as a solution in generating IDE agnostic LL applications.

:(

sad, as I have the sensation that this is what you want right now...

[Sirma Siang]

Posted on November 15, 2017 at 17:37

Hello

,

Great thanks for your feedback.

I have tested your ioc on what will be CubeMX4.0.

Missing rcc file and source file duplication have been corrected.

I attached the generated makefile to that post.

Kind regards

Sirma

________________ Attachments : Makefile.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyIj&d=%2Fa%2F0X0000000b5l%2Fssg6YAWqPDSv9do6ymufuoKeT12mPtZglVLmT1.cOsA&asPdf=false

[Vasile Guta_Ciucur]

Posted on November 16, 2017 at 02:57

These are great news, thank you very much Sirma!

I will continue to report the bugs I find. Hopefully, with the next version I will get the much desired basic functionality.

[Michael B.]

Now it is more than one year later and Cube still creates broken LL projects. Does no-one from ST care?

[Amel NASRI]

Hi @Michael Bürschgens​ ,

Could you please explain the reason behind this assessment?

Does the problem reported in this discussion still being faced?

We are continuously working to improve the solutions offered by ST.

Nevertheless, if you find any limitation, please submit it in a new question here and use relevant topics like: STM32CubeHAL/LL or LL-Drivers (if it is related to LL).

Thanks for your understanding.

-Amel