[arm-gnu] Placing variable at absolute address in RAM
JM
hondgm at yahoo.com
Fri Apr 6 15:56:34 UTC 2012
Thank you, I'm a little closer. It compiles now. But I think there could be another problem that was occurring from the start. I checked the map file for all these variables (structs mostly) that didn't seem to function when in .sram1. I compiled it without specifying a section, then they appear in the mapfile. Also, they are all indicated as being .bss, so I suppose they are uninitialized.
But when I use __attribute__ to force it into .sram1, some variables no longer appear in the map file, BUT, the space being used is shown. Below is an excerpt. See how in main.o all the variables are listed, but in lwiplib.o, only the variable "hello" is displayed? "hello" is a variable I declared to see if it appears in the map file.
/***two declarations that should be appearing in lwiplib.o, but aren't ***/
static struct etharp_entry arp_table[ARP_TABLE_SIZE] __attribute__ ((section(".sram1"))); /*this variable's name not appearing in mapfile*/
unsigned char *hello __attribute__ ((section(".sram1"))); /*this variable's name appears in mapfile*/
/*******************************************************/
.sram1 0x20000000 0x16c load address 0x00028c70
*(.sram1_data)
0x20000000 sram1_bss = .
*(.sram1_bss)
.sram1 0x20000000 0x64 main.o
0x20000000 netbuf_start
0x20000004 netbuf_wr
0x20000008 netbuf_rd
0x2000000c netbuf_end
0x20000010 outbuf1
0x20000014 outbuf2
0x20000018 netbuf
0x2000001c aacFrameInfo
0x2000002c mp3FrameInfo
0x2000003c packetq
.sram1 0x20000064 0x10 ./stream-core/dac.o
0x20000064 dac_fill
.sram1 0x20000074 0xf8 ./general-core/lwiplib.o
0x20000168 hello
0x00028c70 sram1_loadaddr = LOADADDR (.sram1)
________________________________
From: 42Bastian <list-bastian.schick at sciopta.com>
To: arm-gnu at codesourcery.com
Sent: Friday, April 6, 2012 11:26 AM
Subject: Re: [arm-gnu] Placing variable at absolute address in RAM
Hi
> bi/4.5.2/../../../../arm-none-eabi/bin/ld.exe: section .data loaded at [00028bc0,00028bcf] overlaps section .sram1 loaded at [00028bc0,00028c7b]
> collect2: ld returned 1 exit status
> cs-make: *** [RTOSDemo.axf] Error 1
You should not mix AT > with AT(...).
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
_______________________________________________
arm-gnu mailing list
arm-gnu at codesourcery.com
http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/arm-gnu/attachments/20120406/d63065ec/attachment.html>
More information about the arm-gnu
mailing list