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

[Vangelis Fortounas]

Posted on September 09, 2017 at 10:58

Hello!

For some reason  ''stm32l1xx_ll_rcc.c'' is not referenced from your project.

I found that the problem starts when you choose the highlighted options at settings.(first and second)

It is not enough to just change the option in your project.

Make a project without choose this settings  and will be ok

regards

vf

[Vasile Guta_Ciucur]

Posted on September 09, 2017 at 11:25

Thank you very much Vangelis for the detective work and workaround solution! It allows me to go further without waiting for ST update on STM32CubeMX. I will mark your reply as the answer and hope that ST saw this 'bug report'.

[Vasile Guta_Ciucur]

Posted on September 11, 2017 at 00:13

I suppose, problems are deeper. Even with the third option, I don't get the required file included in the Makefile. Yes, the compilation goes ok, no complains, but not a functional code for my board, not even for toggling the included LD2 LED. With, or without the rcc file included in the Makefile. All I add in the while loop is the following:

 /* Infinite loop */ 
 /* USER CODE BEGIN WHILE */ 
 while (1) { /* USER CODE END WHILE */
 /* USER CODE BEGIN 3 */ 
 LL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin); 
 LL_mDelay(500); 
 } 
 /* USER CODE END 3 */
�?�?�?�?�?�?�?�?�?�?

And this, with a newly generated project, without the I2C activated, where all setup was the default one, for my nucleo board (well, I set the OSC32 using the STM32CubeMX interface as having a crystal, as is on board). The LED does not blink.

Is not the LL implementation for this board/micro functional yet when generated for Makefile project?

[Tesla DeLorean]

Posted on September 11, 2017 at 03:31

Does the makefile even explicitly call out the .C files, or just build *.c

Perhaps step the code in the debugger to understand what is happening?

[Vasile Guta_Ciucur]

Posted on September 11, 2017 at 05:06

I can't debug it yet, I am at the beginnings with this microcontroller, only programed PIC and AVR 8bit micros. The project is similar to the one attached already, but without I2C enabled. Basically, The STM32CubeMX loads the initial configuration for selected board and is ready to generate the code. And I generated the code for the Makefile and inserted only those two lines of code. For the same board default configuration I generate code using HAL driver and I get an working application for the OpenSTM32 IDE 

https://github.com/funlw65/my_nucleo_l152re

  . It should work also for the LL driver but it seems this wasn't tested enough before release...

[Vasile Guta_Ciucur]

Posted on September 12, 2017 at 07:09

After the STM32CubeMX update to 4.1 and L1 driver update to 1.8.0 I noted the following:

- choosing the 'Copy only the necessary library files' radio button, allows a compilation without errors;

- the generated code remains un-functional.

I will put this aside, 'till the ST team solves the Low Layer driver for this board (project attached).

Meanwhile, I tried the libopencm3 and the LED blinks. Not an exact delay, but is a good start (the clarity of that API seems a little better to me - for the most advanced things I will look at how the HAL does).

https://nucleobytes.blogspot.ro/2017/09/first-success-with-libopencm3-library.html

Thank you all for your assistance!

________________ Attachments : mk_ll_blink_LD2.tar.gz : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyS5&d=%2Fa%2F0X0000000b7m%2FPQQHSH8Fyffbg7A4sKdtgQQkBT7cGsi_QWYQYOAM9aI&asPdf=false

[Vasile Guta_Ciucur]

Posted on September 15, 2017 at 04:26

Man, is really hard when you are a beginner, the language stays in your way and the ST team considers that is a waste of time to look into a problem that they consider solved with the 1.8.0 version of the driver!

Of course the driver is ok. And of course the provided LL examples within the driver archive are functional and compiles ok.

And of course, I found the error and is in the code generated by STM32CubeMX for a Makefile project. Specifically, in the SystemClock_Config function. As I don't have a debug setup, I copied from a functional LL blink example the SystemClock_Config function and renamed it SystemClock_Config2. Now the LED blinks. I'm attaching the project for the team to figure it. In the main.c file you will have both the original function generated by the Cube and the copied one from the LL example for comparison.

Edit: examining the two function, the Cube's generator code omits to insert the

'LL_FLASH_Enable64bitAccess();'

line of code inside the SystemClock_Config function and the result is non-functional. No big of a deal once you know the reason, but enough for a new version of CubeMX software.

________________ Attachments : ll_blink.tar.gz : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyRq&d=%2Fa%2F0X0000000b7l%2F97u94mhvYtpxwiRzblGu8RDIK2xxn64h9f2Rm2KwY.A&asPdf=false

[Vasile Guta_Ciucur]

Posted on September 16, 2017 at 04:13

Further info on this:

There is a correlation between LL_FLASH_Enable64bitAccess() and LL_mDelay() function. If you omit to insert the LL_FLASH_Enable64bitAccess() at the beginning of the SystemClock_Config function, the following code from inside LL_mDelay function will cause a crash of your app:

 __IO uint32_t tmp = SysTick->CTRL; /* Clear the COUNTFLAG first */ 
 /* Add this code to indicate that local variable is not used */ 
 ((void)tmp); �?�?�?

[Vasile Guta_Ciucur]

Posted on September 16, 2017 at 08:12

And as I said, problems are even deeper.

I can confirm that also for TIMERS (I set TIM6 to generate an exception at every 1ms - using it instead of SysTick), the CubeMX generate incomplete configuration code when you generate for Makefile project. You can set the right configuration only looking at the LL examples that come with the driver archive, to figure what is missing

:(

As example, if you generate code for TIM6, EVENT_UPDATE, in the function MX_TIM6_Init(), the CubeMX 'forgets' to add three lines of code for the function to become usable:

 /* Enable the update interrupt */ 
 LL_TIM_EnableIT_UPDATE(TIM6); 
 /* Enable counter */ 
 LL_TIM_EnableCounter(TIM6); 
 /* Force update generation */ 
 LL_TIM_GenerateEvent_UPDATE(TIM6); �?�?�?�?�?�?�?�?

You can add them manually, but the CubeMX will overwrite them at a new project regeneration,

As it is right now, STM32CubeMX can't be used for a Makefile based project

:(

by a beginner.

Still, I am grateful for the LL examples included in the driver archive that allows me to see how it should be!

Code snippet for 'replacing' Systick with TIM6 with the same 1ms tick:

http://nucleobytes.blogspot.ro/2017/09/tim6-set-for-1ms-timer-using-st-low.html