EmbDev.net

Forum: ARM programming with GCC/GNU tools Problem creating binary when using __attribute__ ((section ("sectionname")))


Author: Joe Dupre (jdupre)
Posted on:

Rate this post
0 useful
not useful
I've just encountered a problem when creating a binary from .elf.  This 
is with YAGARTO toolchain dated 20080928.

Normally the compiler produces an .elf file about 3,900KB in size, and 
from that arm-elf-objcopy creates a .hex of 900KB and a .bin of 320KB.

However, when I use the section attribute to place a variable in a 
specific section of memory, the binary file created is 2,094,081 KB!

Has anyone seen this?  Perhaps there is a problem with my linker script?

My linker defines the memory areas like this:
MEMORY
{
    flash    (rx) : ORIGIN = 0x00000000, LENGTH = 512K  
    ram      (rw) : ORIGIN = 0x40000040, LENGTH = 29888
    ramstack (rw) : ORIGIN = 0x40007500, LENGTH = 2816
    usbram        : ORIGIN = 0x7FD00000, LENGTH = 8K
    ethram        : ORIGIN = 0x7FE00000, LENGTH = 16K
}

And then later in the section section I have:
usbram : { *(.usbram) } > usbram

Then in the program code I declare a variable like this:
int jmd __attribute__ ((section ("usbram"))) = 0;

The fact that this doesn't affect the .elf or .hex output leads me to 
believe this is a bug with the binary output of arm-elf-objcopy.

Any tips?

Author: Jörg Wunsch (dl8dtl) (Moderator)
Posted on:

Rate this post
0 useful
not useful
GCC likely assumes the initialization to zero will be handled by the
run-time startup code, so no additional code is emitted for this.

Apart from that, the only effect of this section should be that the
variable's address is different than if it were in section "ram".

Author: Joe Dupre (jdupre)
Posted on:

Rate this post
0 useful
not useful
Exactly. RAM is getting full.  I need to place some variables in the 
USBRAM section.  That is all.

So why is GCC creating a 2 GIGABYTE .bin file when I declare the 
varible with the section attribute and only a 320K file without??? 
Something is broken.

I just tried with the latest YAGARTO toolchain (arm-elf-objcopy v2.19.1) 
and the same thing is happening.

This does not affect ihex creation, just binary.

Author: Andreas Schwarz (andreas) (Admin) Flattr this
Posted on:

Rate this post
0 useful
not useful
Objcopy is obviously trying to include the usbdata section in the binary 
dump, that's why your file is about 0x7FD00000 bytes big. Remove the 
usbdata section from the objcopy output (-R), use the Intel hex format, 
or prevent the linker from including the section in the elf object - how 
to do that I don't know, but I would expect that simply copying the 
definition of the ram section should do the trick.

Author: Joe Dupre (jdupre)
Posted on:

Rate this post
0 useful
not useful
You're right.  The file size created is exactly the usbram location + 4 
bytes for the variable.  This is weird.

Infortunately I need the binary image, as this code is used for an image 
file uploaded to the device.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
How are you invoking objcopy? You don't want to be using --gap-fill 
because there is a very large gap! Since it is a RAM section, you could 
just remove it with --remove-section= or -R

Author: Joe Dupre (jdupre)
Posted on:

Rate this post
0 useful
not useful
I'm just calling arm-elf-objcopy "normally":
arm-elf-objcopy wallbox.elf -O binary wallbox.bin

Yes, if I add option "-R usbram" the .bin file created is back to the 
300KB range.  But that doesn't help because I need the vars in that 
section!

Bottom line is I am unable to create a usable binary image when I try to 
utilize the usbram section.

In the debugger, everything works fine.  The variables automatically get 
initialized in the usbram memory.  Of course the debugger is using the 
elf output, not the binary.

Author: Jörg Wunsch (dl8dtl) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Joe Dupre wrote:

> Infortunately I need the binary image, as this code is used for an image
> file uploaded to the device.

Then make the uploader more intelligent so it can handle a format like
intel hex or motorola srecord.  As a plain binary image doesn't carry
address information, the only chance is to stuff any gaps with zeros.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
> But that doesn't help because I
> need the vars in that section!

That should not make any difference, the binary only needs to contain 
ROM sections, if it needs to contain RAM sections the code will not run 
from a cold-boot from ROM. The ROM should contain initialisation 
sections that are copied to RAM at run-time. If this is failing, tehn 
you have a different problem I suggest - perhaps your linker script or 
runtime start-up is not correct.

Author: Joe Dupre (jdupre)
Posted on:

Rate this post
0 useful
not useful
I'm not sure which is worse:  not knowing that I don't know what I am 
doing, or knowing that I don't know what I am doing.  Argh.

Author: Joe Dupre (jdupre)
Posted on:

Rate this post
0 useful
not useful
OK, the problem with the large binary was because I did not correctly 
set the load address for the usbram section, so it was filling up the 
space all the way up to the VMA.

Now I know a little bit more about what I am doing.

Author: Francis Kong (dinosaurkfb)
Posted on:

Rate this post
0 useful
not useful
I met this problem too, finally i found i forgot to use "AT" in the 
script to specify the load address.
This has been described clearly in the ld manual.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.