Hi to all
I am using a NXP LPC2378 with the USB interface so I have declared the
USB RAM in the linker script file in order to allocate here buffer for
DMA.
USBRAM (rw) : ORIGIN = 0x7fd00000, LENGTH = (8k)
I have defined a particular location in this ram :
.usbshare (0x7fd01FFC) :
{
*(.usbshare)
*(.usbshare.*)
. = ALIGN(4);
} > USBRAM
. = ALIGN(4);
and then forced the compiler to place a variable there:
BYTE DataRun __attribute__((section(".usbshare")));
well if I compile my file, the dimension of the bin file is about 2G !
!. If I place the DataRun variable elsewere in memory (without the
_attribute_ directive) the bin file is of 167K as should be. If I
insert in the make file the hex format as output , the dimension of the
hex file is correct in both cases.
Did someone have an idea how to resolve ?
Guest
#1664506
> ORIGIN = 0x7fd00000 This are 2 Gigabytes. Thats fine. > Did someone have an idea how to resolve ? I suppose you should use a pointer to that particular address...
Can I tell the linker to set uninitialized data files aside ? The strange thing is that i have used the same notation in another design, and there it works.
I saw now that in the other design the output is hex file,not bin. Using bin fil e the result is the same. The questionnow is : How to generate separated file for data ?
bin files hold a "flat" image of the memory-content. Intel-hex format can handle "memory-holes" since the addresses are included in every record (line). So far I have not used ".output-section (memory-address)" style. You may try to use (NOLOAD) as attribute for the output-section. The binutils ld-manual should provide further information.
Guest
#1664702
I once had the same problem. This resulted in the huge bin file you see: arm-none-eabi-objcopy -O $(FORMAT) $< ./release/$@ Explicitly specifying the desired sections did it for me: arm-none-eabi-objcopy -O $(FORMAT) -j .text -j .isr_vector -j .data $< ./release/$@
Reply
Please log in before posting.