Locating memory sections within program

Hi Johan,

In linker command file ( *.cmd) , you will find those informations about the memory map section's address and size.

I have given a sample linker command file of a raster example of starterware code.

// ============================================================================
// Linker Command File for Linking c674 DSP Programs
//
// These linker options are for command line linking only. For IDE linking,
// you should set your linker options in Project Properties.
//         -c                    Link Using C Conventions
//        -stack     0x1000        Software Stack Size
//        -heap    0x1000        Heap Area Size
// ===========================================================================
-stack 0x1000
-heap 0x1000

// ============================================================================
//                         Specify the System Memory Map
// ============================================================================
MEMORY
{
    L1P:    o = 0x11E00000        l = 0x00008000
    L1D:    o = 0x11F00000        l = 0x00008000
    L2:     o = 0x11800000        l = 0x00040000
    DDR2:   o = 0xC0000000        l = 0x08000000
}

// ============================================================================
//                 Specify the Sections Allocation into Memory
// ============================================================================
SECTIONS
{
    .cinit        >        DDR2               // Initialization Tables
    .pinit        >        DDR2               // Constructor Tables
    .init_array   >        DDR2               // 
    .binit        >        DDR2               // Boot Tables
    .const        >        DDR2               // Constant Data
    .switch       >        DDR2               // Jump Tables
    .text         >        DDR2               // Executable Code
    .text:_c_int00: align=1024 > DDR2         // Entrypoint
    
    GROUP (NEARDP_DATA)                       // group near data
    {
       .neardata
       .rodata
       .bss                                   // note: removed fill = 0
    }             >        DDR2
    .far: fill = 0x0, load > DDR2             // Far Global & Static Variables
    .fardata      >        DDR2               // Far RW Data
    .stack        >        DDR2               // Software System Stack
    .sysmem       >        DDR2               // Dynamic Memory Allocation Area
    
    .cio          >        DDR2               // C I/O Buffer
    .vecs         >        DDR2               // Interrupt Vectors


}

Regards,
Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Thank you for your answer Shankari,

This was not exactly what I was looking for. I did already now that this information could be found in the cmd file as well as in the map file.

What I would like to do is to know the .bss and .far start addresses and sizes from within the compiled program. More specifically I would like the program to be able to check whether an address is a valid pointer to memory within the bss or far sections.

There is always the option of hard coding the addresses and sizes, but I would prefer to provide this information to the program more dynamically, through some compile or link time mechanism. Could this already be available through DSP bios, the CSL or such, or otherwise possible to achievable with reasonable effort?

Best regards

Johan

Hi Johan,

I think, the CCS compiler will take care of this validity of memory sections during building. It will throw you errors if those sections are not correctly allocated to memory sections. You can confirm this by changing the sections of linker.cmd file and re-direct to some other memory sections.

In CCS , if there is any unexpected program termination / memory allocation violation, there exist a exit.c file which gets executed. And also in starterware code, the system configuration libraries were available to take care of exceptions.

By the way, What is the CCS version you use?

For more information on memory allocations, please refer to the following assembly and compiler useguides.

http://www.ti.com/lit/ug/spru186s/spru186s.pdf

http://www.ti.com/lit/ug/spru187q/spru187q.pdf

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Hi Shankari,

Thank you for your answer.

I'm sorry if I haven't been able to properly explain what I need to do. I am not dealing with an issue of verifying allocation at compile/link time, and it is not an issue of program termination/memory allocation issues.

Without getting into how my application works and what it does, it does however actually need to now the start addresses and lengths of the .far and .bss segments in order to make sure that an address points to somewhere within these segments. This is at runtime. Is this possible?

I am using CCS 5.5.0.00077.

Best regards,

Johan

Johan,

Your question is related to the compiler tools and would be best answered in the TI C/C++ Compiler Forum instead of this hardware-centric C6000 Single Core DSP Forum. We are better with hardware issues here, and they are better with software issues there. But since you are already getting some responses, we will not ask a Moderator to move your thread unless you prefer that.

As Shankari mentioned, you need to refer to the Assembly Language Tools Reference Guide for the version of the tools you are using. There will be a section on "Assigning Symbols at Link Time", which is section 8.5.9 in the version I use, spru186x.

There are several subsections there that you will find useful.

If you find an answer for what you wanted, please post what you chose to use here and then mark the thread (your new post) Verified Answer. Or add to your explanation if we do not have the right understanding, yet.

Regards,
RandyP

Hi RandyP,

I really did not realize that this part of the forum was more for hardware issues. I don't mind if the thread stays in this forum if thats okay with you.

The spru186x did indeed have some useful sections in it. I have been trying some stuff in my linker .cmd file, but I can't seem to get the syntax right.

I think both you guys did already understand what I am trying to do. I would like to define the following four symbols so that they are available in my C-code.
1. Start address of .bss

2. End address or size of .bss

3. Start address of .far

4. End address or size of .far

So that in my C code I would be able to do something like

Unt32 lBssStart = _lBssStart; // in C

This is what my linker command file looks like:

		-l"ti\pspiom\platforms\evm6747\lib\Debug\ti.pspiom.platforms.evm6747.evmInit.a674"
-l"ti\pspiom\spi\lib\C6747\Debug\ti.pspiom.spi.a674"
-l"ti\pspiom\i2c\lib\C6747\Debug\ti.pspiom.i2c.a674"
-l"ti\pspiom\psc\lib\C6747\Debug\ti.pspiom.psc.a674"
-l"ti\pspiom\gpio\lib\C6747\Debug\ti.pspiom.gpio.a674"

-l"ti\sdo\edma3\drv\lib\Debug\edma3_drv_bios_c674.lib"
-l"ti\sdo\edma3\rm\lib\c6747\Debug\edma3_rm_bios.lib"
-l"ti\sdo\edma3\drv\sample\lib\c6747\Debug\edma3_drv_bios_sample.lib"

SECTIONS{
		.text: {}  > SDRAM
		.switch: {}  > SDRAM
		.bss: {}  > SDRAM
		.far: {}  > SDRAM
		.cinit: {}  > SDRAM
		.pinit: {}  > SDRAM
		.printf: {}  > SDRAM
		.data: {}  > SDRAM
		.cio: {}  > SDRAM

		CalDataCfgFLASH: {}  > SDRAM
		CalDataFLASH: {}  > SDRAM
		CalDataSpecFLASH: {}  > SDRAM

		.buffers: {}  > DMA_ACCESSIBLE

        GROUP {
         .const: align = 0x8 {}
         .printf (COPY): {}
        } > SDRAM
}

Any suggestions?

Best Regards

Johan

Hi Johan,

Johan says said:

Without getting into how my application works and what it does, it does however actually need to now the start addresses and lengths of the .far and .bss segments in order to make sure that an address points to somewhere within these segments. This is at runtime. Is this possible?

OK. You can do something like below to find it out the exact addresses as well as the validity of memory subsections.

For example, if you hard code the values like below and build it, CCS will throw an error as shown below with the required size of memory needed for .text memory section. In this example, the text size needed is 0x476C. If you change the " .stack         >  0x800000FF " into " .stack         >  0x8000476C" , it will build successfully. In this way you can confirm the exact boundary address of each memory sections. Validity check can be done by CCS directly.

-------------------------------------------------------------------------

/* To find out the boundary of memory sections */

SECTIONS
{
    .text          >  0x80000000  
    .stack         >  0x800000FF  /* This value is an in-correct value purposely done to find out the correct size of .text through compiler error message */

    .bss           >  SHRAM
    .cio           >  SHRAM

..........

........

}

"../OMAPL138.cmd", line 54: error #10099-D: program will not fit into available memory.  run placement with alignment fails for section ".stack" size 0x800 , overlaps with ".text", size 0x476C (page 0)

"../OMAPL138.cmd", line 54: warning #10098-D: specific address 0x800000ff overrides alignment of 4 for ".stack"
error #10010: errors encountered during linking; "simple_hello.out" not built

>> Compilation failure

------------------------------------------------------------------------- 

/* changed to correct value after finding the boundary values */

SECTIONS {     

.text          >  0x80000000     

.stack         >  0x8000476C 

...... 

......

}

<Linking>

'Finished building target: simple_hello.out'

' '

**** Build Finished ****

Regards,

Shankari

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Hi Shankari,

I understand your suggestion. I have other projects involving F28335 and F28035 where it has been solved in similar ways by hard coding the memory map.

In this case however, I the DSP bios is involved quite a lot in the RAM memory mapping. Probably via other .cmd files embedded somewhere in the DSP bios packages. If I start hard coding things in my .cmd file, I can't overlook the potential consequences for the whole project and I am quite happy to not take explicit control over where the sections end up if I don't need to.

I found a lot of useful information in section 8.5.9.1 of spru186x. To me it looks exactly like what I am trying to do. But I can't seem to get the syntax right. One thing I have tried is for example to put the following rows at the end of the .cmd file (below the stuff I appended above)

_lBssStart 	= START(.bss);
_lBssEnd 	= END(.bss);
_lFarStart 	= START(.far);
_lFarEnd 	= END(.far);

which just gives me errors... From the contents of the spru186x I just can't seem to get my head around the syntax. It feels as if it's really just a tiny matter of syntax. Perhaps my "variables" need to be declared somehow.

Best Regards,

Johan

Johan,

It is not very easy to help you with an error message without knowing what the error message is.

The ALT Ref Guide spru186 mentions some predefined constants for some of these same things. Have you tried to use those?

Whether you are writing in assembly or C, you do need to declare your externally defined symbols.

In some cases, until the most recent tools, a symbol in assembly needs to have an underscore "_" inserted at the beginning of the symbol in the C declaration to make it available in C. I think this is discussed in spru186, or maybe in the C Compiler User Guide.

Regards,
RandyP

Hi RandyP,

My project is written entirely in C. But it isn't really the C parts I am having trouble with. Plain C is more of my back yard. It's the .cmd file I can't seem to get right.

Yes, I did find the predefined constants for .bss. The only problem is that there are no predefined constants for the far section. It works fine for bss, but I need information for .far as well.

So, you could put my problem like this:

What should I write in my .cmd file in order to be able to do the same for .far as I am able to do for .bss with the C source lines below?

extern uint32_t __bss__;
extern uint32_t __end__;

void foo( void )
{
    uint32_t ulBssStart;
    uint32_t ulBSSEnd;

    ulBssStart = (uint32_t)&__bss__;
    ulBssEnd = (uint32_t)&__end__;

    /* Go ahead with checking if some address is 
       located within bss. */
}

Thanks for your effort this far.

Regards,

Johan

Ok, so I did some more experimenting. It feels like the solution is really close.

These three lines work when I put them at the end of my .cmd file.

sym1 = 0xAAA;
sym2 = START(SDRAM);
sym3 = END(SDRAM);

They all get a warning however. Company policy is restrictive with writing code that generates warnings, so I would like to understand what is going wrong. Here is the description.

Description    Resource    Path    Location    Type
#10190-D     BMCM_DSP_Debug.cmd    /BMCM_DSP    line 37    C/C++ Problem

When I try to modify the lines that I have above to solve my problem, my guess would be the following two lines:

___far__ = START(.far);
___farEnd__ = END(.far);

Unfortunately that doesn't work at all. Both lines result in the following errors:

Description    Resource    Path    Location    Type
#10345-D     BMCM_DSP_Debug.cmd    /BMCM_DSP    line 35    C/C++ Problem
#10345-D MEM_START(.far,0) has either    BMCM_DSP_Debug.cmd    /BMCM_DSP    line 35    C/C++ Problem

And another warning of the same type as before:

Description    Resource    Path    Location    Type
#10190-D     BMCM_DSP_Debug.cmd    /BMCM_DSP    line 39    C/C++ Problem

Any new suggestions?

Best Regards,

Johan

Johan,

My suggestion is to use the syntax shown in the ALT Ref Guide for START and END. You are not using the commands correctly. They determine the memory section by context and the argument is the symbol you want to define.

See section 8.5.9.7 or search the document for START to find examples of its use in a linker command file.

Regards,
RandyP

RandyP,

I have been reading the linker sections in both spru186 and spru186x back and forth for more than a week, trying all ways to use the START, END and the . (dot) operator to find a solution that I can come up with given the documentation. I simply can't understand how it's supposed to be used. I'm completely stuck.

If you could please provide another example of how they should be used, I would be very thankful.

Regards,

Johan

Johan,

I use the name spru186 generically to mean the latest version, which I believe is spru186x as of today.

Which example of the use of START in spru186 have you based your syntax on? None of the ones I see in section 8.5.9.7 use the . (dot) operator.

I do not have new and different examples. I am a hardware guy. But I think you can use the ones that are in the document where START is actually used, section 8.5.9.7.

Regards,
RandyP

Hi RandyP,

I really appreciate you making an effort, even though this is not your main area of expertise. Perhaps I should get in touch with someone who's more of a compiler person? How should I go about in that case? Ask an admin to move the thread like you suggested in the beginning of the thread (how do I do that?)? Start a new thread in the compiler forum?

I follow you on the documents. Even if it was almost obvious that it was two versions of the same document, I thought there might be some more information to be found by reading multiple revisions.

I base my syntax first on section 8.5.9.1 which clearly describes assignment syntax.

     symbol = expression; assigns the value of expression to symbol

"The symbol should be defined externally. If it is not, the linker defines a new symbol and enters it into the
symbol table."

What surprises me is that a simple statement like

    sym1 = 0xAAA;

generates a warning (#10190-D).

Now I understand what you mean about the argument being the symbol that should be defined. I obviously jumped to conclusions on how to use the operators. START/END etc are operators and not functions as I assumed.

I really can't get my head around how to adapt the examples in 8.5.9.7 to what I am trying to do. I think the key to the problem is that I am trying to work with a whole section like .far, .data, and not just a piece of a file mapped to one of those sections as in the examples.

About the . (dot) operator. I tried to come up with an alternative way to solve the problem. One example was this (within my SECTIONS directive)

    .far: {___far__ = .;}  > SDRAM

It sort of works. The ___far__ symbol is linked to the start address of .far, but I'm not sure if its just a coincidence like

    sym2 = START(SDRAM);

seemed to work. It also generates warnings #10190-D and #10272-D, both without descriptions, and it doesn't solve the problem of finding the end of .far.

If you are out of new leads, could you please ask one of you compiler guys to have a look at this thread, or recommend the best way to get in touch with them?

Regards,

Johan

Hi Johan,

As you mentioned, your post has been moved to CCS forum.

Regards,

Shankari

To understand how to create the symbols you need, please see the section titled Address and Dimension Operators in the C6000 assembly tools manual.  Carefully note how the operators are associated with a specific output section.  To understand how to use those symbols in C/C++, see the section titled Accessing Assembly Language Constants in the C6000 compiler manual.  If you build with the newer EABI, then the symbols are written the same in C and the link command file.  If you use the older COFF ABI, then a symbol in C has an underscore '_' prepended to it in the link command file.

Thanks and regards,

-George

Hi George,

Thank you for you reply.

I have been able to access other symbols like the corresponding predefined ones for the .bss section (__bss__ and __end__), so that part is under control.

I have been trying to solve the other part of this problem using the document you are suggesting, and the address and dimension operators in particular for more than a week now. I've read the document back and forth and tried different ideas about how to define the symbols I need, but I'm really stuck at this point.

I will try to summarize my efforts and ideas this far.

First, here is what my linker command file looks like:

        -l"ti\pspiom\platforms\evm6747\lib\Debug\ti.pspiom.platforms.evm6747.evmInit.a674"
-l"ti\pspiom\spi\lib\C6747\Debug\ti.pspiom.spi.a674"
-l"ti\pspiom\i2c\lib\C6747\Debug\ti.pspiom.i2c.a674"
-l"ti\pspiom\psc\lib\C6747\Debug\ti.pspiom.psc.a674"
-l"ti\pspiom\gpio\lib\C6747\Debug\ti.pspiom.gpio.a674"
-l"ti\sdo\edma3\drv\lib\Debug\edma3_drv_bios_c674.lib"
-l"ti\sdo\edma3\rm\lib\c6747\Debug\edma3_rm_bios.lib"
-l"ti\sdo\edma3\drv\sample\lib\c6747\Debug\edma3_drv_bios_sample.lib"
SECTIONS{
        .text: {}  > SDRAM
        .switch: {}  > SDRAM
        .bss: {}  > SDRAM
        .far: {}  > SDRAM
        .cinit: {}  > SDRAM
        .pinit: {}  > SDRAM
        .printf: {}  > SDRAM
        .data: {}  > SDRAM
        .cio: {}  > SDRAM
        CalDataCfgFLASH: {}  > SDRAM
        CalDataFLASH: {}  > SDRAM
        CalDataSpecFLASH: {}  > SDRAM
        .buffers: {}  > DMA_ACCESSIBLE
        GROUP {
         .const: align = 0x8 {}
         .printf (COPY): {}
        } > SDRAM
}

So my answer will make sense, please get familiar with the terms memory range and output section from this wiki article about linker command files.

You are trying to use the start address of a specific output section.  But this code ...

johan.wolger said:

    sym2 = START(SDRAM);

... doesn't do that.  It gets you the start address of the SDRAM memory range.  This feature is described in the section titled Expressions and Address Operators in the C6000 assembly tools manual.  Note how this creates symbols associated with a memory range, and not an output section.

What you want to do is illustrated in this part of the wiki article on linker command files.  Ignore all the details about loading at one address and running from another address.  You don't need that feature.  Focus on how it creates the symbols associated with that output section.  Note how this is different from creating symbols associated with a memory range.  This is what you need to do.

Thanks and regards,

-George

George,

I am familiar with the difference between a memory range and an output section. I have been trying more or less anything that I can come up with to work out some sort of baseline that I could modify to find a solution. sym2 = START(SDRAM); was just something that happened to not result in an error.

Anyway, I have been doing some more reading and digging.

I think the construct I have been looking for all along is found in section 8.5.9.7.2, namely:

outsect: START(start_of_outsect), SIZE(size_of_outsect)
{
<list of input items>
}

Also, I found that I am already using a similar construct in a F28335 project. I checked how the result looks in that project.

    ramfuncs:      LOAD = FLASHAPP,
                   RUN = RAML0,
                   LOAD_START(_RamfuncsLoadStart),
                   LOAD_END(_RamfuncsLoadEnd),
                   RUN_START(_RamfuncsRunStart),
                   PAGE = 0

So, what I tried to do is this:

.far: START(___far__), END(___farEnd__) {} > SDRAM

or

.far:  {} > SDRAM, START(___far__), END(___farEnd__)

The ___far__ symbol seems to be assigned with the proper place (start address of .far), but END assigns ___farEnd__ with the same value as ___far__. I tried the LOAD/RUN variants of the operators as well with the same result. The linker seems to think that the .far section is 0 bytes long, because the SIZE operators all return 0.

Also, the #10190-D and #10272-D warnings with no descriptions remain when I try all of the mentioned variants.

I also tried the GROUP concept with a dummy section suggested in 8.5.9.6 and tried the 8.5.9.7.3 example with START/END combined with a GROUP with a dummy section in it without any luck.

I think I finally got the syntax right. Now the problem is that the operators don't seem to return what I expect.

I also tried some of the examples above on an initialized section instead, just to check if that could have anything to do with the problem. - Same result there.

Any new suggestions?

Best Regards,

Johan

johan.wolger said:

The linker seems to think that the .far section is 0 bytes long

That's possible.  Are you sure you have some non-empty .far input sections?  If so, what output section are they going in?  Look in the map file to see.

johan.wolger said:

Also, the #10190-D and #10272-D warnings with no descriptions remain when I try all of the mentioned variants.

You don't show enough details to say anything further.  I need to see these diagnostics in full context from the build Console window, not the Problems view.

Thanks and regards,

-George

Hi George,

I have plenty of stuff going into the .far section judging from the map file.

This is what the section allocation map looks like.

.far       0    c0000400    0004bbac     UNINITIALIZED
                  c0000400    0003b0d2     MYOBJ1.obj (.far)
                  c003b4d2    00000002     --HOLE--
                  c003b4d4    00000004     bios6747.a674 : bcache_wait.o674 (.far)
                  c003b4d8    00004900     edma3_drv_bios_c674.lib : edma3_drv_init.obj (.far)
                  c003fdd8    00002dc8     edma3_rm_bios.lib : edma3resmgr.obj (.far)
                  c0042ba0    0000264c     MYOBJ2.obj (.far)
                  c00451ec    00000004     bios6747.a674 : clk_data.o674 (.far)
                  c00451f0    000018b0     MYOBJ3.obj (.far)
                  c0046aa0    00001280     edma3_rm_bios.lib : edma3_rm_gbl_data.obj (.far)
                  c0047d20    00000ae8                       : edma3_c6747_cfg.obj (.far)
                  c0048808    000009f0     ti.pspiom.gpio.a674 : Gpio.obj (.far)
                  c00491f8    00000764     MYOBJ3.obj (.far)
                  c004995c    00000004     rts6740.lib : errno.obj (.far)
                  c0049960    00000670     ti.pspiom.i2c.a674 : I2c.obj (.far)
                  c0049fd0    00000558     ti.pspiom.spi.a674 : Spi.obj (.far)
                  c004a528    000004dc     MYOBJ4.obj (.far)
                  c004aa04    00000004     rts6740.lib : fopen.obj (.far)
                  c004aa08    000003d0     MYOBJ5.obj (.far)
                  c004add8    0000039c     edma3_drv_bios_sample.lib : bios_edma3_drv_sample_c6747_cfg.obj (.far)
                  c004b174    00000004     rts6740.lib : sinit.obj (.far)
                  c004b178    00000378     MYOBJ6.obj (.far)
                  c004b4f0    00000324     rts6740.lib : defs.obj (.far)
                  c004b814    00000004     --HOLE--
                  c004b818    00000188                 : atexit.obj (.far)
                  c004b9a0    0000011c                 : lowlev.obj (.far)
                  c004babc    00000004     --HOLE--
                  c004bac0    00000100     ti.pspiom.psc.a674 : Psc.obj (.far)
                  c004bbc0    000000d8     bios.a674 : knl.o674 (.far)
                  c004bc98    000000a0     SpiDrv.obj (.far)
                  c004bd38    0000007c     MYOBJ7.obj (.far)
                  c004bdb4    0000005c     bios.a674 : tsk.o674 (.far)
                  c004be10    00000054               : obj_init.o674 (.far)
                  c004be64    00000050               : tsk_stup.o674 (.far)
                  c004beb4    0000002c     I2cDrv.obj (.far)
                  c004bee0    00000020     bios.a674 : sys.o674 (.far)
                  c004bf00    00000020     edma3_drv_bios_sample.lib : bios_edma3_drv_sample_init.obj (.far)
                  c004bf20    00000018     rtdx64xplus.lib : rtdx_mon.o64P (.far)
                  c004bf38    00000010     bios.a674 : exc.o674 (.far)
                  c004bf48    00000010               : gio_cfg.o674 (.far)
                  c004bf58    00000010               : knl_tick.o674 (.far)
                  c004bf68    0000000c               : utl_putc.o674 (.far)
                  c004bf74    0000000c     rts6740.lib : exit.obj (.far)
                  c004bf80    00000008     bios.a674 : ecm_dispatch.o674 (.far)
                  c004bf88    00000008               : gio.o674 (.far)
                  c004bf90    00000008               : sem_crea.o674 (.far)
                  c004bf98    00000008     rts6740.lib : _lock.obj (.far)
                  c004bfa0    00000008                 : trgdrv.obj (.far)
                  c004bfa8    00000004     bios.a674 : dev_init.o674 (.far)

I changed the names of my application modules to MYOBJ1 to MYOBJ7 before publishing for security reasons. There are plenty of symbols mapped to .far under the input file sections in the SYMBOL DEFINITIONS BY INPUT FILE area of the map file.

When I try the same syntax for the .text output section (.text:  RUN_START(___far__), RUN_END(___farEnd__) {} > SDRAM), it goes completely wrong. The linker puts another uninitialized .text section with zero length in the sections allocation map. So I get:

SECTION ALLOCATION MAP

...a whole bunch of output sections first...

.far       0    c0000400    0004bbac     UNINITIALIZED
     (with a lot of input sections)

.text      0    c0000400    00000000     UNINITIALIZED
     (no input sections mapped)

.printf    0    c0000400    00000000     COPY SECTION

.sys       0    c004bfac    00000010     UNINITIALIZED
    (one section mapped)

.args      0    c004bfbc    00000004     ]
    (one section mapped)

.text      0    c004bfc0    0002b260    
    (with a lot of input sections)

The same goes for the .far section (which is really what I want to do, as you already know), but in that case the start addresses of the two .far output sections just happen to be the same.

And the details from the build console:

"../BMCM_DSP_Debug.cmd", line 44: remark #10191-D: object ".printf" is not
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 29: warning #10190-D:
   allocated, but is being placed as part of allocated object "GROUP_1"
   absolute symbol "___far__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 44: remark #10191-D:
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 29: warning #10190-D:
   object ".printf" is not allocated, but is being placed as part of allocated
   absolute symbol "___farEnd__" being redefined
   object "GROUP_2"
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 29: warning #10190-D:
   absolute symbol "___far__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 29: warning #10190-D:
   absolute symbol "___farEnd__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 29: warning #10272-D:
   section relative symbols from different output sections cannot be mixed;
   "___far__" is in section ".far", "DOT operator" is in section ".far"
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 29: warning #10272-D:
   section relative symbols from different output sections cannot be mixed;
   "___farEnd__" is in section ".far", "DOT operator" is in section ".far"

Any new ideas George?

Best Regards,

Johan

I agree that .far is not empty.

Based on your error messages, I'm pretty sure you need these changes.

• Define the .printf output section only once.  An example in an earlier post defines it twice.
• Define any global symbol (such as ___far__) only one time.  This means a global symbol can appear in the linker command file only once (with rare exceptions).
• I don't see why you ever need to use the DOT operator.  These look like "symbol = ." or something similar.  Remove them.

I can't guarantee these changes will solve all your problems.  But you'll get much closer.

Thanks and regards,

-George

Thank you for your reply George,

The funny thing about the error messages is that I do only define the global symbol ___far__ once, and I don't use the DOT operator anywhere. But as you point out the error messages indicates something else.

So in my original command file I have the following two definitions for the .printf section

.pinit:                > SDRAM

and a bit further down the list there is

        GROUP {
         .const: align = 0x8 {}
         .printf (COPY): {}
        } > SDRAM

When I try to remove the first one I get the following result:

"../BMCM_DSP_Debug.cmd", line 45: remark #10191-D: object ".printf" is not
   allocated, but is being placed as part of allocated object "GROUP_1"
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 45: remark #10191-D:
   object ".printf" is not allocated, but is being placed as part of allocated
   object "GROUP_2"

And when I remove entry inside the group statement it seems to link without warnings. But isn't the .printf (COPY): {} statement inside the group definition there for a reason?

So, when I rewrite my command file to look like this:

        -l"ti\pspiom\platforms\evm6747\lib\Debug\ti.pspiom.platforms.evm6747.evmInit.a674"
-l"ti\pspiom\spi\lib\C6747\Debug\ti.pspiom.spi.a674"
-l"ti\pspiom\i2c\lib\C6747\Debug\ti.pspiom.i2c.a674"
-l"ti\pspiom\psc\lib\C6747\Debug\ti.pspiom.psc.a674"
-l"ti\pspiom\gpio\lib\C6747\Debug\ti.pspiom.gpio.a674"

-l"ti\sdo\edma3\drv\lib\Debug\edma3_drv_bios_c674.lib"
-l"ti\sdo\edma3\rm\lib\c6747\Debug\edma3_rm_bios.lib"
-l"ti\sdo\edma3\drv\sample\lib\c6747\Debug\edma3_drv_bios_sample.lib"


SECTIONS{
        .text:                 > SDRAM
        .switch:             > SDRAM
        .bss:                 > SDRAM

        .far:  RUN_START(___far__), RUN_END(___farEnd__) > SDRAM
        .cinit:             > SDRAM
        .pinit:                > SDRAM
        .printf:            > SDRAM
        .data:                > SDRAM
        .cio:                > SDRAM

        CalDataCfgFLASH:    > SDRAM
        CalDataFLASH:        > SDRAM
        CalDataSpecFLASH:    > SDRAM

        .buffers:            > DMA_ACCESSIBLE

        GROUP {
         .const: align = 0x8 {}
        } > SDRAM
}

It still gives this result in the build console:

'Building target: BMCM_DSP.out'
'Invoking: C6000 Linker'
"C:/ti/ccsv5/tools/compiler/c6000_7.4.4/bin/cl6x" -mv6740 --abi=coffabi -O1 -ms1 -g --define=DSP --display_error_number --issue_remarks --diag_warning=225 -z -m"BMCM_DSP.map" -i"C:/ti/ccsv5/tools/compiler/c6000_7.4.4/lib" -i"C:/ti/ccsv5/tools/compiler/c6000_7.4.4/include" -i"C:/Program Files/Texas Instruments/pspdrivers_01_30_01/packages" -i"C:/Program Files/Texas Instruments/edma3_lld_01_11_02_05/packages" -i"C:/ti/bios_5_42_01_09/packages/ti/rtdx/lib/c6000" -i"C:/ti/bios_5_42_01_09/packages/ti/bios/lib" --reread_libs --warn_sections --xml_link_info="BMCM_DSP_linkInfo.xml" --mapfile_contents=sym_defs --rom_model -o "BMCM_DSP.out" -l"./BMCM_DSPcfg.cmd"  "./Common/BCPBalancingManager/source/BCPBalancingManager.obj" "./Common/CommonBase/source/FloatVectorOp.obj" "./Common/CommonBase/source/ChkSum.obj" "./Common/CommonBase/source/BitVector.obj" "./Common/Hal/source/SpiDrv.obj" "./Common/Hal/source/I2cDrv.obj" "./Common/Hal/source/Gpio.obj" "./Common/Hal/source/EEpromHndl.obj" "./Common/Modules/source/state_estimate.obj" "./Common/Modules/source/sop.obj" "./Common/Modules/source/soh.obj" "./Common/Modules/source/matop.obj" "./Common/Modules/source/error.obj" "./Common/Modules/source/ekf.obj" "./Common/Modules/source/cell_param.obj" "./Common/Modules/source/cell_ocv.obj" "./Common/Modules/source/cell_model.obj" "./Common/Modules/source/cell_main.obj" "./Common/Modules/source/NVRamMgr.obj" "./Common/Modules/source/MCUMgr.obj" "./Common/Modules/source/ErrHndlLight.obj" "./Common/Modules/source/CellWrapper.obj" "./Common/ProjectBase/source/YodaParentProjectInherrited/TEBS_TECAN_protocol.obj" "./Common/ProjectBase/source/YodaParentProjectInherrited/SeedKey_protocol.obj" "./Common/ProjectBase/source/YodaParentProjectInherrited/MCU_ICU_protocol.obj" "./Common/ProjectBase/source/YodaParentProjectInherrited/MCU_DSP_protocol.obj" "./Modules/source/main.obj" "./Modules/source/lut_param.obj" "./Modules/source/lut_ocv.obj" "./Modules/source/DSPCalSpecData.obj" "./Modules/source/DSPCalData.obj" "./Modules/source/DSPCalCfg.obj" "./Modules/source/CalData.obj" "./BMCM_DSPcfg_c.obj" "./BMCM_DSPcfg.obj" "../BMCM_DSP_Debug.cmd" -l"C:\Program Files\Texas Instruments\dsplib_c674x_3_1_0_0\lib\dsplib.a674" -l"C:\Program Files\Texas Instruments\mathlib_c674x_3_0_1_1\lib\mathlib.a674" -l"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd" -l"rts6740.lib"
<Linking>
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 19: warning #10190-D:
   absolute symbol "___far__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 19: warning #10190-D:
   absolute symbol "___farEnd__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 19: warning #10190-D:
   absolute symbol "___far__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 19: warning #10190-D:
   absolute symbol "___farEnd__" being redefined
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 19: warning #10272-D:
   section relative symbols from different output sections cannot be mixed;
   "___far__" is in section ".far", "DOT operator" is in section ".far"
"C:/SVN/TEBS/SW/4011_Dooku/BMCM/DSP/Trunk/application/Implementation\BMCM_DSP_Debug.cmd", line 19: warning #10272-D:
   section relative symbols from different output sections cannot be mixed;
   "___farEnd__" is in section ".far", "DOT operator" is in section ".far"
'Finished building target: BMCM_DSP.out'
' '
Another interesting thing that I found is that there is a second linker command file which is invoked during linking of this project. In there, the exact same thing as I am trying to do is done for some other sections without generating any warnings or errors. It's a large file, so I attach it to this reply so you can see if it could have anything to do with the problem. Had to change the file type however, because of the forum file uploader.

/*   Do *not* directly modify this file.  It was    */
/*   generated by the Configuration Tool; any  */
/*   changes risk being overwritten.                */

/* INPUT BMCM_DSP.cdb */

/* MODULE PARAMETERS */
-u _commonInit
GBL_USERINITFXN = _commonInit;

-u SDRAM
MEM_SEGZERO = SDRAM;
-u SDRAM
MEM_MALLOCSEG = SDRAM;

-u _CLK_gethtime
CLK_TIMEFXN = _CLK_gethtime;
-u HWI_F_dispatch
CLK_HOOKFXN = HWI_F_dispatch;

-u _KNL_tick
PRD_THOOKFXN = _KNL_tick;

-u IRAM
RTDX_DATAMEMSEG = IRAM;

-u IRAM
HST_DSMBUFSEG = IRAM;

-u GBL_NULL
SWI_EHOOKFXN = GBL_NULL;
-u GBL_NULL
SWI_IHOOKFXN = GBL_NULL;
-u SWI_F_exec
SWI_EXECFXN = SWI_F_exec;
-u SWI_F_run
SWI_RUNFXN = SWI_F_run;

-u MEM_NULL
TSK_STACKSEG = MEM_NULL;
-u _FXN_F_nop
TSK_VCREATEFXN = _FXN_F_nop;
-u _FXN_F_nop
TSK_VDELETEFXN = _FXN_F_nop;
-u _FXN_F_nop
TSK_VEXITFXN = _FXN_F_nop;

-u IDL_F_stub
IDL_CALIBRFXN = IDL_F_stub;

-u _UTL_doAbort
SYS_ABORTFXN = _UTL_doAbort;
-u _UTL_doError
SYS_ERRORFXN = _UTL_doError;
-u _UTL_halt
SYS_EXITFXN = _UTL_halt;
-u _UTL_doPutc
SYS_PUTCFXN = _UTL_doPutc;

-u _FXN_F_nop
GIO_CREATEFXN = _FXN_F_nop;
-u _FXN_F_nop
GIO_DELETEFXN = _FXN_F_nop;
-u _FXN_F_nop
GIO_PENDFXN = _FXN_F_nop;
-u _FXN_F_nop
GIO_POSTFXN = _FXN_F_nop;

/* OBJECT ALIASES */
_CACHE_L2 = CACHE_L2;
_CACHE_L1P = CACHE_L1P;
_CACHE_L1D = CACHE_L1D;
_SDRAM = SDRAM;
_IRAM = IRAM;
_L3_CBA_RAM = L3_CBA_RAM;
_DMA_ACCESSIBLE = DMA_ACCESSIBLE;
_PRD_clock = PRD_clock;
_RTA_fromHost = RTA_fromHost;
_RTA_toHost = RTA_toHost;
_HWI_RESET = HWI_RESET;
_HWI_NMI = HWI_NMI;
_HWI_RESERVED0 = HWI_RESERVED0;
_HWI_RESERVED1 = HWI_RESERVED1;
_HWI_INT4 = HWI_INT4;
_HWI_INT5 = HWI_INT5;
_HWI_INT6 = HWI_INT6;
_HWI_INT7 = HWI_INT7;
_HWI_INT8 = HWI_INT8;
_HWI_INT9 = HWI_INT9;
_HWI_INT10 = HWI_INT10;
_HWI_INT11 = HWI_INT11;
_HWI_INT12 = HWI_INT12;
_HWI_INT13 = HWI_INT13;
_HWI_INT14 = HWI_INT14;
_HWI_INT15 = HWI_INT15;
_EVENT4 = EVENT4;
_EVENT5 = EVENT5;
_EVENT6 = EVENT6;
_EVENT7 = EVENT7;
_EVENT8 = EVENT8;
_EVENT9 = EVENT9;
_EVENT10 = EVENT10;
_EVENT11 = EVENT11;
_EVENT12 = EVENT12;
_EVENT13 = EVENT13;
_EVENT14 = EVENT14;
_EVENT15 = EVENT15;
_EVENT16 = EVENT16;
_EVENT17 = EVENT17;
_EVENT18 = EVENT18;
_EVENT19 = EVENT19;
_EVENT20 = EVENT20;
_EVENT21 = EVENT21;
_EVENT22 = EVENT22;
_EVENT23 = EVENT23;
_EVENT24 = EVENT24;
_EVENT25 = EVENT25;
_EVENT26 = EVENT26;
_EVENT27 = EVENT27;
_EVENT28 = EVENT28;
_EVENT29 = EVENT29;
_EVENT30 = EVENT30;
_EVENT31 = EVENT31;
_EVENT32 = EVENT32;
_EVENT33 = EVENT33;
_EVENT34 = EVENT34;
_EVENT35 = EVENT35;
_EVENT36 = EVENT36;
_EVENT37 = EVENT37;
_EVENT38 = EVENT38;
_EVENT39 = EVENT39;
_EVENT40 = EVENT40;
_EVENT41 = EVENT41;
_EVENT42 = EVENT42;
_EVENT43 = EVENT43;
_EVENT44 = EVENT44;
_EVENT45 = EVENT45;
_EVENT46 = EVENT46;
_EVENT47 = EVENT47;
_EVENT48 = EVENT48;
_EVENT49 = EVENT49;
_EVENT50 = EVENT50;
_EVENT51 = EVENT51;
_EVENT52 = EVENT52;
_EVENT53 = EVENT53;
_EVENT54 = EVENT54;
_EVENT55 = EVENT55;
_EVENT56 = EVENT56;
_EVENT57 = EVENT57;
_EVENT58 = EVENT58;
_EVENT59 = EVENT59;
_EVENT60 = EVENT60;
_EVENT61 = EVENT61;
_EVENT62 = EVENT62;
_EVENT63 = EVENT63;
_EVENT64 = EVENT64;
_EVENT65 = EVENT65;
_EVENT66 = EVENT66;
_EVENT67 = EVENT67;
_EVENT68 = EVENT68;
_EVENT69 = EVENT69;
_EVENT70 = EVENT70;
_EVENT71 = EVENT71;
_EVENT72 = EVENT72;
_EVENT73 = EVENT73;
_EVENT74 = EVENT74;
_EVENT75 = EVENT75;
_EVENT76 = EVENT76;
_EVENT77 = EVENT77;
_EVENT78 = EVENT78;
_EVENT79 = EVENT79;
_EVENT80 = EVENT80;
_EVENT81 = EVENT81;
_EVENT82 = EVENT82;
_EVENT83 = EVENT83;
_EVENT84 = EVENT84;
_EVENT85 = EVENT85;
_EVENT86 = EVENT86;
_EVENT87 = EVENT87;
_EVENT88 = EVENT88;
_EVENT89 = EVENT89;
_EVENT90 = EVENT90;
_EVENT91 = EVENT91;
_EVENT92 = EVENT92;
_EVENT93 = EVENT93;
_EVENT94 = EVENT94;
_EVENT95 = EVENT95;
_EVENT96 = EVENT96;
_EVENT97 = EVENT97;
_EVENT98 = EVENT98;
_EVENT99 = EVENT99;
_EVENT100 = EVENT100;
_EVENT101 = EVENT101;
_EVENT102 = EVENT102;
_EVENT103 = EVENT103;
_EVENT104 = EVENT104;
_EVENT105 = EVENT105;
_EVENT106 = EVENT106;
_EVENT107 = EVENT107;
_EVENT108 = EVENT108;
_EVENT109 = EVENT109;
_EVENT110 = EVENT110;
_EVENT111 = EVENT111;
_EVENT112 = EVENT112;
_EVENT113 = EVENT113;
_EVENT114 = EVENT114;
_EVENT115 = EVENT115;
_EVENT116 = EVENT116;
_EVENT117 = EVENT117;
_EVENT118 = EVENT118;
_EVENT119 = EVENT119;
_EVENT120 = EVENT120;
_EVENT121 = EVENT121;
_EVENT122 = EVENT122;
_EVENT123 = EVENT123;
_EVENT124 = EVENT124;
_EVENT125 = EVENT125;
_EVENT126 = EVENT126;
_EVENT127 = EVENT127;
_KNL_swi = KNL_swi;
_TSK_idle = TSK_idle;
_MainTask = MainTask;
_IDL_cpuLoad = IDL_cpuLoad;
_LNK_dataPump = LNK_dataPump;
_RTA_dispatcher = RTA_dispatcher;
_LOG_system = LOG_system;
_trace = trace;
_DVTEvent_Log = DVTEvent_Log;
_IDL_busyObj = IDL_busyObj;

/* MODULE GBL */

SECTIONS {
   .vers (COPY): {} /* version information */
}

-priority
--trampolines
--"diag_suppress=16002"
-llnkrtdx.a674
-llog8.a674
-ldrivers.a674         /* device drivers support */
-lsioboth.a674         /* supports both SIO models */
-lbios6747.a674        /* BIOS clock specific library */
-lbios.a674            /* DSP/BIOS support */
-lrtdx64xplus.lib      /* RTDX support */
-lrts6740.lib          /* C and C++ run-time library support */

_GBL_CACHE = GBL_CACHE;
_BCACHE_bootInit=_BCACHE_setCacheToSram;

/* MODULE MEM */
-stack 0x4000
MEMORY {
   CACHE_L2    : origin = 0x11820000,  len = 0x20000
   CACHE_L1P   : origin = 0x11e00000,  len = 0x8000
   CACHE_L1D   : origin = 0x11f00000,  len = 0x8000
   SDRAM       : origin = 0xc0000400,  len = 0x3fffc00
   IRAM        : origin = 0x11804000,  len = 0x1c000
   L3_CBA_RAM  : origin = 0x80000000,  len = 0x20000
   DMA_ACCESSIBLE : origin = 0xc0000000, len = 0x400
}
/* MODULE CLK */
SECTIONS {
   .clk: {
        *(.clk) 
   } > IRAM, RUN_START(CLK_A_TABBEG) 
}
_CLK_PRD = CLK_PRD;
_CLK_COUNTSPMS = CLK_COUNTSPMS;
_CLK_REGS = CLK_REGS;
_CLK_USETIMER = CLK_USETIMER;
_CLK_TIMERNUM = CLK_TIMERNUM;
_CLK_TDDR = CLK_TDDR;

/* MODULE PRD */
SECTIONS {
   .prd: RUN_START(PRD_A_TABBEG), RUN_END(PRD_A_TABEND) {
   } > IRAM
}
PRD_A_TABLEN = 0;

/* MODULE RTDX */
_RTDX_interrupt_mask = 0x0;

/* MODULE HST */
_LNK_dspFrameReadyMask = LNK_dspFrameReadyMask; 
_LNK_dspFrameRequestMask = LNK_dspFrameRequestMask; 
_LNK_readDone = LNK_readDone; 
_LNK_readFail = LNK_readFail; 
_LNK_readPend = LNK_readPend; 
_LNK_writeFail = LNK_writeFail;
_HWI_CFGDISPATCHED = HWI_CFGDISPATCHED;

/* MODULE SWI */
SECTIONS {
   .swi: RUN_START(SWI_A_TABBEG), RUN_END(SWI_A_TABEND) {
   } > IRAM
}
SWI_A_TABLEN = 1;

/* MODULE TSK */
SECTIONS {
   .tsk: {
        *(.tsk) 
   } > IRAM
}

/* MODULE IDL */
SECTIONS {
   .idl: {
        *(.idl) 
   } > IRAM, RUN_START(IDL_A_TABBEG)
   
   .idlcal: {
        *(.idlcal) 
   } > IRAM, RUN_START(IDL_A_CALBEG) 
}


LOG_A_TABLEN = 3; _LOG_A_TABLEN = 3;

PIP_A_TABLEN = 2;


SECTIONS {
        .dsm: {} > IRAM

        .TSK_idle$stk: {
            *(.TSK_idle$stk)
        } > IRAM

        .MainTask$stk: {
            *(.MainTask$stk)
        } > IRAM

        /* LOG_system buffer */
        .LOG_system$buf: align = 0x1000 {} > IRAM

        /* trace buffer */
        .trace$buf: align = 0x10000 {} > IRAM

        /* DVTEvent_Log buffer */
        .DVTEvent_Log$buf: align = 0x200 {} > IRAM

        .rtdx_data: align = 0x40 { . += 0x80; *(.rtdx_data) }   > IRAM

       /* RTA_fromHost buffer */
       .hst1: align = 0x4 {} > IRAM

       /* RTA_toHost buffer */
       .hst0: align = 0x4 {} > IRAM

        .trace: fill = 0x0  align = 0x4 {
           _SYS_PUTCBEG = .;
           . += 0x200;
           _SYS_PUTCEND = . - 1;
        } > IRAM

        .hst: RUN_START(HST_A_TABBEG), RUN_START(_HST_A_TABBEG), RUN_END(HST_A_TABEND), RUN_END(_HST_A_TABEND) {
        } > IRAM

        .log: RUN_START(LOG_A_TABBEG), RUN_START(_LOG_A_TABBEG), RUN_END(LOG_A_TABEND), RUN_END(_LOG_A_TABEND) {
        } > IRAM

        .pip: RUN_START(PIP_A_TABBEG), RUN_START(_PIP_A_TABBEG), RUN_END(PIP_A_TABEND), RUN_END(_PIP_A_TABEND) {
        } > IRAM

        .sts: RUN_START(STS_A_TABBEG), RUN_START(_STS_A_TABBEG), RUN_END(STS_A_TABEND), RUN_END(_STS_A_TABEND) {
        } > IRAM

        .hwi_vec: {
            *(.hwi_vec)
        } align = 0x400, RUN_START(HWI_A_VECS) > SDRAM

        .sysdata: {} > SDRAM

        .udev: {} > SDRAM

        .mem: 	  {} > SDRAM

        .bios:    {} > SDRAM

        .gio:     {} > SDRAM

        .sys:     {} > SDRAM

        .sysregs: {} > SDRAM

        .devtable: {} > SDRAM

        .gblinit:    {} > SDRAM

        .sysinit:    {} > SDRAM

        .trcdata:    {} > SDRAM

        .hwi: {}  > SDRAM

        .rtdx_text: {}  > SDRAM

        .args: align=4 fill=0 {
            *(.args)
            . += 0x4;
        } > SDRAM

        .stack: align = 0x8 {
            GBL_stackbeg = .;
            *(.stack)
            GBL_stackend = GBL_stackbeg + 0x4000 - 1;
            _HWI_STKBOTTOM = GBL_stackbeg + 0x4000 - 8;
            _HWI_STKTOP = GBL_stackbeg;
        } > SDRAM

        .SDRAM$heap: {
            . += 0x1000;
        } RUN_START(SDRAM$B), RUN_START(_SDRAM_base), RUN_SIZE(SDRAM$L), RUN_SIZE(_SDRAM_length) > SDRAM

}

Best Regards,

Johan

I can't explain this.  I'd like to try to reproduce it.  Can you submit your CCS project?

Thanks and regards,

-George

Ok George. It would be great if you had a look at the project. I'll PM you a link where you can download it. This project is full of core IP, so I made a copy where more or less all of the application layer is cleaned out. Fortunately the problem with the .far section linker commands remain after the cleaning, so you should be able to reproduce the problems I'm experiencing.

Best Regards,

Johan

Well done George!

Everything works as expected after removing the command file duplicate. That was indeed a tricky thing to spot.

Thanks a ton for helping me out.

Best Regards,

Johan

So, I'm sorry to say that I'm back with more issues related to this command file thing.

Everything looked fine (judging from the map file) until I actually tried to access the symbols that was defined by the linker.

In the command file:
.far:  RUN_START(___far__), RUN_END(___farEnd__) > SDRAM

The entries in the map file looks similar to the automatically generated symbols (such as ___bss__ and ___end__). Using the test project that I sent you, George, I get the following entries under the global symbols list:
c0042280   ___bss__
c0042af2   ___end__
c0030b7c   ___farEnd__
c00224c0   ___far__

Obtaining the addresses of the bss symbols work fine in the following way:

/* Declaration in main.c */
extern uint32_t __bss__;
extern uint32_t __end__;
extern uint32_t __far__;
extern uint32_t __farEnd__;

static uint32_t m_ulTest;

/* Try to access the symbols */
void AppMain(void)
{

    m_ulTest = (uint32_t)&__bss__;

    if( m_ulTest > 10 )
    {
	/* Just some dummy code to avoid variable access being optimized away. */
        InitGPIO();
    }

    m_ulTest = (uint32_t)&__far__;
    if( m_ulTest > 10 )
    {
        WriteGPIO_pin( GPIO_CH_OUT_LED4, LED_ON );
    }

}

For bss it works fine when I look at the value of m_ulTest after assigning the bss start to it (the end works as well). But for far it doesn't work.

It generates two linker warnings

"../Modules/source/main.c", line 48: warning #17009-D: relocation type is
   static base-relative, but references symbol "___far__" defined in section
   ".far"; references to section ".far" are not relative to any static base, so
   this relocation cannot be performed (type = 'R_C60BASE' (80), file =
   "./Modules/source/main.obj", offset = 0x00000008, section = ".text")
"../Modules/source/main.c", line 48: warning #17009-D: relocation type is
   static base-relative, but references symbol "___farEnd__" defined in section
   ".far"; references to section ".far" are not relative to any static base, so
   this relocation cannot be performed (type = 'R_C60BASE' (80), file =
   "./Modules/source/main.obj", offset = 0x0000001c, section = ".text")
warning #10015-D: output file "BMCM_DSP.out" cannot be loaded and run on a
   target system

I also tried doing the same thing for some of the other output sections defined in my command file, such as .text and .switch. The result was similar.

This must really be a matter of some tiny detail...

Can you reproduce the problem, George? Please tell me if you need to have the project resent.

Best Regards,

Johan

Great George,

Tested and commited now. Thank you very much.

Best Regards,

Johan