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?

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".

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.

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.

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.

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

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.

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.

> 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.

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.

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.

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.