This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Understanding the Ram Linker

Hi all,

I'm using the 28027_RAM_Ink.cmd as provided (I know this because I destroyed my last linker and had the re-install control suite to get a fresh copy) and need some help understanding whats going on...

preface:

using CCS V5.something

Dev board - F28027 launchPad

Working on a 'TestPad' for InstaSpin - Rotary Encoder/ Current Sense/PWM out & SPI OLED

I have 2 large-ish headers - X11 colours && Font

Initial Error: 

Description Resource Path Location Type
<a href="file:/C:/ti/ccsv5/tools/compiler/dmed/HTML/10099.html">#10099-D</a> program will not fit into available memory. placement with alignment/blocking fails for section ".text" size 0xc53 page 0. Available memory ranges: 28027_RAM_lnk.cmd /InstaSPIN Bench line 114 C/C++ Problem


I figured immediately that the logical solution to this is to simply expand the memory allocated to .text, evidently not as simple as I thought.  I changed these: 
PRAML0     : origin = 0x008000, length = 0x000900
DRAML0      : origin = 0x008900, length = 0x000700

to this

PRAML0     : origin = 0x008000, length = 0x001000
DRAML0      : origin = 0x008900, length = 0x000600

which stopped all errors but now the play button is greyed out and there is no way to start the program???

After some investigation into the memory (sprs523j.pdf pg 16) I see that 0x00 9000 is reserved -doesn't make much sense since the original linker also had DRAML0 flowing into this region? It also shows another SARAM block at 0x3F8000, so I figured I would just move PRAML0 here since there is not much using it - such that the only thing difference in my 28027_RAM_lnk.cmd to the one provided in control suite is :
PRAML0     : origin = 0x3F8000, length = 0x001000

But unfortunately this results in the same problem - builds fine but the play button is greyed out////

Last resort, move PRAML0 to flash....
PRAML0     : origin = 0x3F0000, length = 0x005000

Success! -Interrupt still crashes the MCU for some reason, but that is a different matter.)

This is not ideal as I am doing a lot of debugging and erasing the flash sectors takes a lot of time....

Why did my original 'fix' not work? There is surely enough room in RAM for this - only just came up with this error when I added a 'draw box' routine....

CCS not flagging an error makes trouble shooting very painful - I may have some fundamental misunderstanding of the linker because this makes no sense to me.

Thanks in advance

  • Hi Patrick,

    Patrick Fisher2 said:
    After some investigation into the memory (sprs523j.pdf pg 16) I see that 0x00 9000 is reserved

    Patrick, yes, that is correct, 0x9000 is reserved.

    Patrick Fisher2 said:
    doesn't make much sense since the original linker also had DRAML0 flowing into this region?

    Patrick Fisher2 said:

    PRAML0     : origin = 0x008000, length = 0x000900
    DRAML0      : origin = 0x008900, length = 0x000700

    I haven't checked the file but if I understand the above ranges were in the original file?  If so then DRAML0 goes up to 0x9000. i.e.   8900h + 700h = 9000h.   If that is not the case then let me know and I will check/file a bug against the original file.

    Patrick Fisher2 said:
    PRAML0     : origin = 0x008000, length = 0x001000
    DRAML0      : origin = 0x008900, length = 0x000600

    We have unified memory on C28x devices.  This means that "data space" and "program space" at the same address are actually the same physical memory.  With the above allocation the PRAML0 now overlaps with DRAML0 which won't work properly.

    8000h + 1000h = 9000h == overlaps with DRAML0

    Some more details can be found here:

    http://processors.wiki.ti.com/index.php/C28x_Compiler_-_Understanding_Linking#PAGE_0_or_PAGE_1

    Patrick Fisher2 said:
    It also shows another SARAM block at 0x3F8000, so I figured I would just move PRAML0 here since there is not much using it - such that the only thing difference in my 28027_RAM_lnk.cmd to the one provided in control suite is :
    PRAML0     : origin = 0x3F8000, length = 0x001000

    The block at 0x3f8000 is a remapping of the L0 memory block.  it is the same physical block but remapped for some compatibility with an older product line (240x).   In general either mapping can be used, but both are the same physical block so my suggestion is to stick to one or the other. 


    Hope this helps.  This wiki page may also be of use.  http://processors.wiki.ti.com/index.php/C28x_Compiler_-_Understanding_Linking

    Regards

    Lori