AnsweredAssumed Answered

Stm32l-discovery gcc link errors

Question asked by diviney.noel on Feb 19, 2012
Latest reply on Nov 28, 2012 by Clive One
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: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: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: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: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: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: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: 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();
    __NOP();  __NOP();    __NOP();  __NOP();
    __NOP();  __NOP();    __NOP();  __NOP();
    __NOP();  __NOP();    __NOP();  __NOP();
    __NOP();  __NOP();    __NOP();  __NOP();
    __NOP();  __NOP();    __NOP();  __NOP();
    __NOP();  __NOP();    __NOP();  __NOP();
    __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"); }
   { __ASM volatile ("nop");  __ASM volatile ("nop"); __ASM volatile ("nop"); __ASM volatile ("nop"); }
   { __ASM volatile ("nop");  __ASM volatile ("nop"); __ASM volatile ("nop"); __ASM volatile ("nop"); }
   { __ASM volatile ("nop");  __ASM volatile ("nop"); __ASM volatile ("nop"); __ASM volatile ("nop"); }
   { __ASM volatile ("nop");  __ASM volatile ("nop"); __ASM volatile ("nop"); __ASM volatile ("nop"); }
   { __ASM volatile ("nop");  __ASM volatile ("nop"); __ASM volatile ("nop"); __ASM volatile ("nop"); }
   { __ASM volatile ("nop");  __ASM volatile ("nop"); __ASM volatile ("nop"); __ASM volatile ("nop"); }
   { __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.

Outcomes