[arm-gnu] Placing variable at absolute address in RAM

[JM]

I'm interested in what you did, but the attached file is formatted badly so I'm having a lot of trouble following it.  One line is 800 characters long; the formatting probably got screwed up.  

I've been coming to the realization that I have to define sections to do this.  But what I don't understand is how, when the RAM is split into three or more sections, will the linker treat the multiple "available" sections.  Let me explain.

Out of the 96K RAM, it ends up being allocated roughly like this with one section:

0K - 12K : global and static variables
12K - 96K : available for dynamic allocation

I can't place these 16 bytes into the latter area since it's the heap.  But, it can go into the first area.  So say I split it into sections of roughly these sizes:

.section1: 0 - 464 bytes: global and static variables
.section2: 464 bytes - 480 bytes: DMA structure
.section3: 480bytes - 96K: global, static variables, and heap


The question is, how do I tell the linker that .section1 and .section2 should be treated equally, that is, both are available for automatic allocation by the linker?  The answer may be in Bob's linker file, but I'm really ignorant about linker files (not that I haven't tried).





________________________________
 From: Bob Brusa <bob.brusa at gmail.com>
To: arm-gnu at codesourcery.com 
Sent: Thursday, April 5, 2012 5:31 AM
Subject: Re: [arm-gnu] Placing variable at absolute address in RAM
 
Am 04.04.2012 16:33, schrieb JM:
> Hello
>
> I've researched this, asked on other forums, and so far I'm no closer.
>
> I'm trying to place a variable at a specific address in RAM on a TI ARM
> Cortex-M3. I have good reason for doing so, which I can explain briefly:
>
> The micro I'm using, LM3S9B92 has a DMA controller. There are 32 DMA
> channels and each channel requires a 16 byte struct in RAM for
> housekeeping. These 32 structs are placed into an array, which is 512
> bytes if you do the math, and must be placed on a 1024 byte boundary.
> Now....the datasheet indicates that the RAM for unused DMA channels can
> be used for something else. I'm using only one DMA channel, which is
> near the end of the list. If it were near the beginning, this would be
> easier to recover at least some of the wasted RAM by simply not making
> the array 32 members long.
>
> So what I want to do is reserve 16 bytes of RAM at a strategic location.
> It must be 464 bytes from a 1024 byte boundary. This I believe will
> allow the lone DMA channel to function and not allocate unused RAM.
>
> I believe this will involve the linker script, and possibly Makefile.
> I'm ok with Makefile modifications. The linker file I'm almost clueless
> on. Any ideas? My current linker file is below:
>
> MEMORY
> {
> FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K
> SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 96K
> }
>
> SECTIONS
> {
> .text :
> {
> KEEP(*(.isr_vector))
> *(.text*)
> *(.rodata*)
> _etext = .;
> } > FLASH
>
> .data : AT (ADDR(.text) + SIZEOF(.text))
> {
> _data = .;
> *(vtable)
> *(.data*)
> _edata = .;
> } > SRAM
>
> .bss(NOLOAD) :
> {
> _bss = .;
> *(.bss*)
> *(COMMON)
> _ebss = .;
> . = ALIGN (8);
> _end = .;
> } > SRAM
> }
>
> /* end of allocated ram _end */
> PROVIDE( _HEAP_START = _end );
>
> /* end of the heap -> align 8 byte */
> PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM) + LENGTH(SRAM),8) );
>
>
>
>
>
>
> _______________________________________________
> arm-gnu mailing list
> arm-gnu at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/arm-gnu
Hi,
two years ago I had a similar problem. I needed an area at a fixed 
address in flash and an other at a known place in ram - with the 
requirement, that this part of the ram should not be initialized upon 
startup of the program. And here is what I did:

The trick is to define new sections. For the flash case I added the 
following lines at the beginning of the relevant source:

#define EEPromArea    0x400
cyg_uint8 eeprombottom[EEPromArea]  __attribute__ ((section (".eeromemu")));

and for the sram case (nvv_t is a user-defined type):

nvv_t nvv __attribute__ ((section (".sticky")));

The standard loader file then needs a few modifications - see attachment.

Hope this helps.
Regards Bob





_______________________________________________
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/20120405/fd61d4c3/attachment.html>