How to solve linker error ''Undefined symbol'' ? in KEIL uVision5 ?

[Marco Israel]

Posted on January 01, 2018 at 17:01

Hello,

I implemented the folloing codesnipped (using to set the USART baudrate). :

    uint32_t periphclk = LL_RCC_GetUSARTClockFreq(LL_RCC_USART2_CLKSOURCE);

    uint32_t oversampling = LL_USART_GetOverSampling(USART2);

    if (periphclk != LL_RCC_PERIPH_FREQUENCY_NO)

    {

        LL_USART_SetBaudRate(USART2,

            periphclk,

            oversampling,

            BAUDRATE);

    }

But I get the following linking error out ouf the first snipping line:

.\Objects\simpel_gpio_test.axf: Error: L6218E: Undefined symbol LL_RCC_GetUSARTClockFreq (referred from main.o).

Not enough information to list image symbols.

Not enough information to list load addresses in the image map.

Can someone explain me, how to give the linker the needed information? If I use a hardcoded periphclk  or if I use  __LL_RCC_* macros like __LL_RCC_CALC_MSI_FREQ(), the code compile and link without erros....

I'm using KEIL uVison5.

Does some hase any idea? ...

Thank you so much

[Tesla DeLorean]

Posted on January 01, 2018 at 17:29

Linker complaining you don't provide source for the code you call, review what source is in the project.

Add 

stm32l4xx_ll_rcc.c 

to the project (or equivalent for STM32 family being used)

STM32Cube_FW_L4_V1.10.0\Drivers\STM32L4xx_HAL_Driver\Src\stm32l4xx_ll_rcc.c

[Andrew Neil]

Posted on January 01, 2018 at 18:09

Exactly the same way you'd solve it in any other toolchain!

This is basic programming stuff; not specific to Keil; not specific to embedded - not even specific to 'C' !

http://c-faq.com/decl/decldef.html

 

[Marco Israel]

Posted on January 02, 2018 at 13:12

Hello and thank you for your replay !

I know that it is 'basic' stuff. But I defined the need Flag 'USE_FULL_LL_DRIVER', The file is in my project (like other files which compile without problems) and I add the needed lib paths to the project setting. I have currently no idea, which I forgot for this file... 

The function isn't also 'static' (but this would be an error in this stm file...)

[Andrew Neil]

Posted on January 02, 2018 at 14:37

How & where did you define that flag?

IS the file actually being compiled?

[Marco Israel]

Posted on January 03, 2018 at 11:23

Hello Adrew,

I make the #define in my main.h, before the howl includes. The file compiles without erros, like all other ones and I get the object.o files. Other libs (like the ll_usart) works without errors (need the same #define 'USE_FULL_LL_DRIVER' ...

[Andrew Neil]

Posted on January 03, 2018 at 11:59

 ,

 ,

Marco Israel wrote:

I make the ♯ define in my main.h, before the howl (sic) includes.

Should that say, 'HAL includes' ?

But does it also need to be seen by the LL/HAL source files ... ?

Try it in Project defines ...

[Marco Israel]

Posted on January 04, 2018 at 13:20

Yesterday I solved the problem already. I added the define also in the

stm32l4xx_ll_rcc

.c

lib source file. Not nice, but 'it works for me' and now the linker is also happy...  I don't know, why I need this only in this file, not in other ones which also need this flag ... 

Thank you for your help and 

kind regards.

[Andrew Neil]

Posted on January 04, 2018 at 13:46

 ,

 ,

As noted previously, the correct place to do this is in the Project Defines - then you don't have to go manually editing individual files.

I guess this is what the User Manual means when it says (my emphasis):

5.14 How are LL initialization APIs enabled?

The definition of LL initialization APIs and associated resources (structure, literals and prototypes) is conditioned by the USE_FULL_LL_DRIVER compilation switch. To be able to use LL APIs,

add this switch in the toolchain compiler preprocessor.

It could be clearer.

http://www.st.com/content/ccc/resource/technical/document/user_manual/74/09/3d/80/f9/39/4c/c7/DM00157440.pdf/files/DM00157440.pdf/jcr:content/translations/en.DM00157440.pdf

 ,

Marco Israel wrote:

I don't know, why I need this only in this file

Did you not spot, right at the top of that file:

/**

 ,

******************************************************************************

 ,

* @file stm32l4xx_ll_rcc.c

 ,

* @author MCD Application Team

 ,

* @version V1.6.0

 ,

* @date 28-October-2016

 ,

* @brief RCC LL module driver.

 ,

******************************************************************************

 ,

:

:

*/

 ,

♯ if defined(USE_FULL_LL_DRIVER)

[Tesla DeLorean]

Posted on January 04, 2018 at 14:46

There should be Keil Template LL projects under the source/example trees, if those build correctly review the structure and project metadata (defines, include paths, etc)

ST usually passes a define for the CPU and the Library being used. Include path order can make a differences if you have multiple instance of the same files

[Marco Israel]

Posted on January 05, 2018 at 11:38

Thank you Andrew, and yes it works if I make the #define in the  project settings...

Easy, if you know where (in which document and in which part) you find the needed information and how to understand it, mostly is clear ...hopefully ... or not ... 

But mostly it feels like I search at the wrong places ...

:(

 

And thank you Clive, yes maybe I take the templates next time. I know about it... But I like to do it on may own to learn what I had/must do (or what I have not done and forgot) to learn my stuff... Out of errors you learn mostly the most in my opinion ... after you find the solution.... Sometimes this is a hard way to learn...

:(