Topic : Ride7 data segment size and default linker script issue - STM32

Forum : ARM

Original Post
Post Information Post
March 17, 2010 - 12:41pm
Guest

Hi,

I'm having an issue where the Ride7 data segments don't seem to tie up with the linker script. I'm not too clued up with this so hopefully someone can help me out.

Essentially, I am using the STM32F101C8T6 (64k flash, 10k RAM). And I'm doing a project without external ram, so everything needs to fit into the 10k.

When I compile, the code/data size text (blue text) next to my project in Ride7 says "text=24580 data=1004 bss=8796". Which to me is all good, since the data section (1004+8796 = 9800+256(min stack size)) which is still smaller than 10k.
However, when looking at the linker script, I saw the following section:

/* Memory Spaces Definitions */

MEMORY
{
RAM (xrw) : ORIGIN = 0x68000000, LENGTH = 64K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K
FLASHB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB0 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB1 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB2 (rx) : ORIGIN = 0x00000000, LENGTH = 0
EXTMEMB3 (rx) : ORIGIN = 0x00000000, LENGTH = 0
}

To test that the data segments were really less than 10k, I changed the RAM(xrw) to LENGTH=10k. This then doesn't link, and says "region RAM overflowed by 3596 bytes".

How is this possible? And how can it be by that much?!
So in short, if I dont put a restriction in the linker script, then it links and says its less than 10k in the IDE. But put the restriction in, and it says it has overflowed.

Please help.

Regards
Mark
Replies
Post Information Post
+1
0
-1
March 17, 2010 - 1:30pm
Guest

Hmmm, doing some map file fishing, I found where the 3596 byte overflow comes from...

My data section finishes @ 0x68002648. (max RAM address being 0x68002800). Then there's a whole bunch of new sections with a length of 0xfc4 (see below), I've pasted a section of the map file below. Its these sections make it overflow.

?RandomExtraData?(0xfc4) - [max RAM (0x68002800) - appData (0x68002648)] = 0xE0C (3596 bytes)

----------------------------------------------FROM MAP FILE--------------------------------------------------
DISCARD 0x68002648 0xfc4 load address 0x0800768c
libc.a(*)
.debug_frame 0x68002648 0x2c c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-closer.o)
.ARM.attributes
0x68002674 0x27 c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-closer.o)
*fill* 0x6800269b 0x1 00
.vfp11_veneer 0x6800269c 0x0 c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-closer.o)
.janus_2cc_veneer....
.
.etc
.
.
.etc
.
*fill* 0x6800360b 0x1 00
.vfp11_veneer 0x6800360c 0x0 c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/thumb2\libgcc.a(_arm_fixunssfsi.o)
.janus_2cc_veneer
0x6800360c 0x0 c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/thumb2\libgcc.a(_arm_fixunssfsi.o)
.v4_bx 0x6800360c 0x0 c:/program files/raisonance/ride/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.3.2/thumb2\libgcc.a(_arm_fixunssfsi.o)
----------------------------------------------FROM MAP FILE END----------------------------------------

Does anyone know what these sections are? And whether they're important or not?

Can I just forget about limiting the linker script to 10k because the extra 0xfc4 of 'random data' will be discarded anyway because of the DISCARD section, making my app less than 10k in the end?

From http://www.ipp.mpg.de/~dpc/gnu/ld-2.9.1/html_mono/ld.html => "The special secname `/DISCARD/' may be used to discard input sections. Any sections which are assigned to an output section named `/DISCARD/' are not included in the final link output."

Thanks
Mark
+1
0
-1
March 18, 2010 - 10:57am
Guest

Hi Mark

I think you can test with latest software version.
Here I get a script link with 10k of RAM.
It might a mistake in memory size definition which has been corrected since then.

Regards
Matloub