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

1

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.