#19 Templates mem.ld

[asier70]

To simplify mem.ld file I suggest little modification:

_estack = 0x20000000 + $(STM32F1ramSize)*1024;

to

_estack = ORIGIN(RAM) + LENGTH(RAM);

[Liviu Ionescu (ilg)]

thank you, good idea, please check for it in the next release.

[Liviu Ionescu (ilg)]

the startup code, including the linker scripts, were reworked, for both templates, F1 and F4.
could you try the new beta version?
it is available from

http://gnuarmeclipse.sourceforge.net/updates-test

[asier70]

I've just instaled the newest test update. During creating STM32F10x v3.5 Lib project I met a problem:

%STM32F4xx.miscDir.label contents . . is Invalid. Expected pattern is "[a-zA-Z0-9]+"

Project was created by can't be compiled..

cs-make: *** [libs/_writeSTM32F4xx.miscDir.default/src/_write.o] Error 1

There is probably buggy %STM32F4xx.miscDir..default folder.
Also libs folder is shown twice.
Unused declaration of extern void_start(void);
I use windows XP and eclipse kepler. It's my first test of your templates.

[Liviu Ionescu (ilg)]

sorry, the F1 template was copy/pasted from the F4 template, and one 'paste' was missing :-(

could you try again?

[asier70]

I did plugin upgrade. Problem with %STM32F4xx is solved now.
I've found that I had problems because I named my project using space between words.. After using underline space in the name, project compiles without problems. Template for F4xx also compiles successfully now, but in problems section there are errors like uint32_t could not been resolved or type BLIBKPORT could be not resolved. I don't know why Kepler indexer generates that errors only for F4xx template but compilation is succesfull. For F10x template indexer solves the problems quickly. For F4xx indexer work slowly but finally problems remains.
Using space in project name generates linker problem:

'Building target: Test F103.elf'
'Invoking: Cross ARM C Linker'
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wall -g3 -T libs.ld -T mem.ld -T sections.ld -nostartfiles -Xlinker --gc-sections -L"../ldscripts" -Wl,-Map,"Test F103.map" -o "Test F103.elf" ./src/main.o ./libs/misc/src/_write.o ./libs/misc/src/debug_impl.o ./libs/StdPeriph/src/misc.o ./libs/StdPeriph/src/stm32f10x_adc.o ./libs/StdPeriph/src/stm32f10x_bkp.o ./libs/StdPeriph/src/stm32f10x_can.o ./libs/StdPeriph/src/stm32f10x_cec.o ./libs/StdPeriph/src/stm32f10x_crc.o ./libs/StdPeriph/src/stm32f10x_dac.o ./libs/StdPeriph/src/stm32f10x_dbgmcu.o ./libs/StdPeriph/src/stm32f10x_dma.o ./libs/StdPeriph/src/stm32f10x_exti.o ./libs/StdPeriph/src/stm32f10x_flash.o ./libs/StdPeriph/src/stm32f10x_fsmc.o ./libs/StdPeriph/src/stm32f10x_gpio.o ./libs/StdPeriph/src/stm32f10x_i2c.o ./libs/StdPeriph/src/stm32f10x_iwdg.o ./libs/StdPeriph/src/stm32f10x_pwr.o ./libs/StdPeriph/src/stm32f10x_rcc.o ./libs/StdPeriph/src/stm32f10x_rtc.o ./libs/StdPeriph/src/stm32f10x_sdio.o ./libs/StdPeriph/src/stm32f10x_spi.o ./libs/StdPeriph/src/stm32f10x_tim.o ./libs/StdPeriph/src/stm32f10x_usart.o ./libs/StdPeriph/src/stm32f10x_wwdg.o ./libs/CMSIS/src/core_cm3.o ./libs/CMSIS/src/startup_cm.o ./libs/CMSIS/src/startup_stm32f10x.o ./libs/CMSIS/src/system_stm32f10x.o ./libs/CMSIS/src/vectors_stm32f10x.o
'Finished building target: Test F103.elf'
' '
cs-make: *** No rule to make target Test', needed bysecondary-outputs'. Stop.

[Liviu Ionescu (ilg)]

I don't know why Kepler indexer generates that errors only for F4xx template

yes, the indexer is a bit strange, you need to regenerate the index to get rid of those errors.

Using space in project name generates linker problem

using spaces in project names is a CDT bug that I fixed some times ago, the fix will probably be public with Kepler SR2, in january 2014.

please read the 'known issues' and FAQ pages, for more details.

but what is your opinion on the linker scripts, do you have further suggestions?

[asier70]

Regarding to linker scripts I can say that I'm not expert but your work seems to be very interesting. I like .after_vectors section that is not only for readbility of the listing. Some time ago I had to modify my linker script to put Reset_Handler and Default_handler after vectors because after changes in project this procedures often changed their location in memory. After flash reloading program started in previous location what was strange (some vectors are shadowed in memory and not refreshed after flash change and software reset).