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

[JM]

The custom allocator could work, but I can see some problems with that in my application.  Actually setting up the multiple regions in the linker isn't so bad, but I've run into a problem maybe somebody can shed some light on.  


I manually chose several static and global variables to go into SRAM1 using "__attribute__ ((section(".sram1")))", and this works pretty well linker-wise.  The problem is, some of these variables no longer function.  I can't say how exactly because they are from a third party library (lwIP) and I haven't debugged yet, but I know if I let the linker allocate automatically, they're ok.  

All these variables that cause issues are static.  However, being static itself doesn't seem to be problematic, that is, some static variables are happy there.  Is there any problem with putting static variables in to region SRAM1 that anyone can see?  I assume there's a simple answer to this.  New linker below:



MEMORY
{
    FLASH (rx) : ORIGIN = 0x00001000, LENGTH = 252K
    SRAM1 (rwx) : ORIGIN = 0x20000000, LENGTH = 464
    DMA (rwx) : ORIGIN = 0x200001D0, LENGTH = 16
    SRAM2 (rwx) : ORIGIN = 0x200001E0, LENGTH = 97824
}

SECTIONS
{
    .text :
    {
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)
        _etext = .;
    } > FLASH

    .data : AT (ADDR(.text) + SIZEOF(.text))
    {
        _data = .;
        *(vtable)
        *(.data*)
        _edata = .;
    } > SRAM2

    .bss(NOLOAD) :
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        _ebss = .;
        . = ALIGN (8);
       _end = .;
    } > SRAM2
    
    .dmaRegisters  0x200001D0 (NOLOAD) : 
    {
        *(.dmaRegisters)
    } > DMA    
    
    .sram1  0x20000000 (NOLOAD) : 
    {
        *(.sram1)
    } > SRAM1    
}

/* end of allocated ram _end */
PROVIDE( _HEAP_START = _end );

/* end of the heap -> align 8 byte */ 
PROVIDE ( _HEAP_END = ALIGN(ORIGIN(SRAM2) + LENGTH(SRAM2),8) );




________________________________

A simple sequential allocator for a system that allocates memory but doesn't free it. That's pretty common.

This question has nothing to do with the compiler, and all of your questions on use of the linker should be answered in "The Gnu Linker Manual" which comes with a CodeSourcery distribution.

> If I did this in my case, it would leave 400-500
> bytes unused.

I can think of at least three ways to solve this (before breakfast :-), but I'll only list two.

The unnecessarily complicated sledgehammer-and-peanut way is to use the linker to declare THREE separate named memory regions. The "tiny fixed address region" that you need somewhere in the heap, the chunk before and the chunk after. You then modify your custom allocater to be smart enough to allocate from the TWO regions named in the linker. All it has to do is to try to allocate from the first, and if that fails, to allocate from the second instead. The first one will eventually fill up with small requests so you won't be wasting more than a few bytes. That's so simple it'd only take a few lines of code and two static variables at most.

The really simple way is to have the Allocator able to handle two regions, and have it hard-allocate the DMA block during its initialisation and thereafter allocate from the region before and the region after like listed previously. That's what I'd do.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/arm-gnu/attachments/20120406/74ef11b4/attachment.html>