Stm32l-discovery gcc link errors

divner · ‎2012-02-18

Posted on February 19, 2012 at 06:26

Hi,

I am using Codesourcery gcc to build the stm32l-discovery demo.

I get the following linking error

./Debug/src_icc_measure_Ram.o: In function `EnterLPRUNModeRAM':

C:/CodeLite-embed/msys/home/Projects/Stm32f1L_Discovery_demo/App/src/icc_measure_Ram.c:109: relocation truncated to fit: R_ARM_THM_CALL against `__NOP'

C:/CodeLite-embed/msys/home/Projects/Stm32f1L_Discovery_demo/App/src/icc_measure_Ram.c:110: relocation truncated to fit: R_ARM_THM_CALL against `__NOP'

C:/CodeLite-embed/msys/home/Projects/Stm32f1L_Discovery_demo/App/src/icc_measure_Ram.c:111: relocation truncated to fit: R_ARM_THM_CALL against `__NOP'

C:/CodeLite-embed/msys/home/Projects/Stm32f1L_Discovery_demo/App/src/icc_measure_Ram.c:111: additional relocation overflows omitted from the output

collect2: ld returned 1 exit status

mingw32-make.exe[1]: *** [Debug/App.elf] Error 1

On investigation this is a result of having an array of __NOP() macro calls which are defined in cm3.h as

static __INLINE void __NOP() { __ASM volatile (''nop''); }

One __NOP() works ok but if one has two or more a linker error is generated.

I have got the program to work by changing the code from

do{

__NOP(); __NOP(); __NOP(); __NOP();

} while((USERBUTTON_GPIO_PORT->IDR & USERBUTTON_GPIO_PIN) == 0);

to

do{

{ __ASM volatile (''nop''); __ASM volatile (''nop''); __ASM volatile (''nop''); __ASM volatile (''nop''); }

} while((USERBUTTON_GPIO_PORT->IDR & USERBUTTON_GPIO_PIN) == 0);

There is a similar problem with the __WFE(); macro. One is ok but two in succession fail

Again the solution is to use { __ASM volatile (''wfe''); }

The bizarre thing is that the Atollic gcc compiler does not give any errors.

In addition to the above the code in this demo produces a host of warnings which indicates very lazy and sloppy programming. Atollic's solution seems to be to turn the warnings off.

Best regards,

Noel Diviney.

lutfi_faisah · ‎2012-11-28

Posted on November 28, 2012 at 16:30

Thank u, it works..

and

why others

do not experience

this problem

??

Best Regards

Lutfi_Indonesia

frankmeyer9 · ‎2012-11-28

Posted on November 28, 2012 at 16:49

__NOP is not actually a function called, but one of the intrinsics supplied by the ARM header files (core_cmInstr.h in this case).

If you check that file, you will notice that this intrinsics are multiply defined, one definition for every toolchain/compiler.

Check that your make file / project settings define the proper toolchain macro.

For Codesourcery, this is __GNUC__, IMHO.

Tesla DeLorean · ‎2012-11-28

Posted on November 28, 2012 at 16:59

and

why others

do not experience

this problem

??

Probably because frankly a lot of people use more professional tools that explicitly target embedded code. GNU/GCC is a more general solution, and while powerful it has many options which are mostly hidden when you code in an IDE, and just press a button.

The problem described above seems to be one of the compiler failing to actually INLINE the code properly and doing a NEAR call to a subroutine that subsequently goes out of scope when the linker tries to resolve the calls.

You'd have to look at what compiler/linker version and options were doing to understand what was happening with the toolchains that worked vs did not.

The STM32L-Discovery project is supplied in an IAR/EWARM only format, along with all the quirks of that specific tool chain.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..