• State TI Thinks Resolved
  • Locked Locked
  • Replies 19 replies
  • Answers 8 answers
  • Subscribers 98 subscribers
  • Views 699 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320C5505: TMS320C5509 Linker Command File.

RAMESH GANESAMOORTHY
Prodigy 30 points
Part Number: TMS320C5505
Other Parts Discussed in Thread: SPRC133

Hello,

How to create a dummy section in the linker file?. I would like to create the output file without allocating the memory or filling the data in the DUMMY section of the output file ?..  With the below example I cant move FPRG above DUMMY or below CODE. The problem is with DUMMY or without DUMMY section the output file size is same. 

MEMORY
{
MMR : origin = 0x000000, length = 0x0000C0
CRC : origin = 0x0000F0, length = 0x000002
SECA: origin = 0x0000F2, length = 0x000002
DUMMY : origin = 0x020000, length = 0x020000
FPRG: origin = 0x040000, length = 0x004000
CODE : origin = 0x044000, length = 0x020000

}

SECTIONS
{
.mmr : > MMR
.crc : > CRC
.seca: > SECA
.dummy : > DUMMY, type = DSECT
.fprg: > FPRG
.code :> CODE

}

Thank you,

Ramesh G

  • 0
    TI__Guru 55345 points

    Hi Ramesh,

    If you create a memory section (for example DUMMY), but do not put any data or code into it, then the final output file size will not be affected at all. If you want to create a region in the output file, then you have to not only create a memory section, but also put some data/code sections (for example, .dummy) into it, even though the data/code in .dummy section is garbage.

    Best regards,

    Ming 

  • 0 in reply to Ming Wei
    Prodigy 30 points

    Thank you so much for the prompt response Ming. Per the above code snippet I was expecting the output file size should not include DUMMY section but I do see the output file filled with 0's for the DUMMy section and size is increased. Also, I'm getting the same size If I dont put the DUMMY section ( SKIP the DUMMY Section). Please advise. 

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    The key is the usage of the .dummy usage in your program. If you have variables, arrays or functions put into the .dummy section, then it does not matter what you have in the linker command file, the memory will be allocation for the .dummy section. What the .dummy :> DUMMY is to dictate where you want put the .dummy section. If the .dummy:> Dummy is not defined in the linker command file, the linker will assign it into the default memory location.

    If you want to declare a data buffer, but do not want to fill it with 0 or make it visible in the OUT file, then you can either use the data pointer as the start of the data buffer, then assign a pre-allocated memory section to the data pointer. Or you can use the dynamically allocated data buffer.

    Best regards,

    Ming 

  • 0 in reply to Ming Wei
    Prodigy 30 points

    Hi Ming,

    Yes, I dont want to fill it with 0 for the DUMMy section or make it visible in the .out or .bin file. If you could point me an example for the data pointer start of the data buffer then assign to pre-allocated memory section to the data pointer would helpful. thank you..

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    The implementation is very simple:

    1. Find a section of on-chip memory, for example, from 0x10000 to 0x18000 (32KB).

    2. Remove it from the memory section from linker command file (or DSP/BIOS), so that no data section will be put into it.

    3. Define a data pointer of 16-bit integer (or your data type) int16 *my_pre_allocated_buffer = (int16 *)0x10000;

    4. Start access to this buffer using *(my_pre_applocated_buffer+offset) (offset should be  >= 0 and < 0x4000)

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Prodigy 30 points

    I followed the below steps and still I see the output file (.out/.bin) same size as before with lot of 0's filled out in the binary file. Do I need to initialize the entire buffer ?   
    1. Identified the memory location (i.e. origin: 0x020000 and length is 0x020000)
    2. Removed the above dummy memory section from the linker command file.
    3. defined the data pointer as : Int16 *dummyCodeSecIOBuf = (Int16*)0x020000;
    4. set the buffer as *(dummyCodeSecIOBuf+0x01FFFF) = 0xBEEF;

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    H Ramesh,

    Can you check on the MAP file for the arrays located in the areas where were filled with 0? If you find such arrays, then simply undefine those arrays and replace them with the data pointers.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Prodigy 30 points

    Hi Ming,

    I double checked the .map file and it appears that not many places filled with 0's other than the below ones. These are similar to the unmodified build. I generated the .map file by moving initialization line i.e (*(dummyCodeSecIOBuf+0x01FFFF) = 0xBEEF;) into a function. 

    If I initialize file global with *(dummyCodeSecIOBuf+0x01FFFF) = 0xBEEF; or *(dummyCodeSecIOBuf) = 0 compiler throws error : error #78-D: this declaration has no storage class or type specifier, error #148: declaration is incompatible with "Int16 *dummyCodeSecIOBuf" , error #145: a value of type "unsigned int" cannot be used to initialize an entity of type "int *"


  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    Keep in mind, the power off the EVM also clears the on-chip memory to 0.

    You should have used the following:

     *(dummyCodeSecIOBuf+0x01FFFF) = (Int16)0xBEEF

    because the dummyCodeSecIOBuf is Int16 while the 0xBEEF is "unsigned int"

    Also just a reminder, the C5509 only has 64KB DARAM and 192KB SARAM. Total 256KB on-chip memory. Address space 0x00000 to 0x3FFFF.

    I do not understand why the following memory sections are defined in the linker command file:

    FPRG: origin = 0x040000, length = 0x004000
    CODE : origin = 0x044000, length = 0x020000

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Prodigy 30 points

    I'm seeing the same error with the *(dummyCodeSecIOBuf+0x01FFFF) = (Int16)0xBEEF code change and also I observed same error Uint16.
    Uint16 *dummyCodeSecIOBuf = (Uint16*)0x020000;
    *(dummyCodeSecIOBuf+0x01FFFF) = (Uint16)0xBEEF;

    Correct, Per C5509 address space is 0x00000 to 0x3FFFF. We have external SDRAM so I'm trying to configure the code to the external SDRAM (i.e. External - CE0) as code size cant fit within the internal RAM so trying to move it out to the external RAM (will be slow compared to internal RAM for sure) and leave the DUMMY section as it is which causes output file size issue (i.e. filled with zero's).

    I reduced the code size and updated below memory definition in the linker file the output file size is 128Kb

    MMR : origin = 0x000000, length = 0x0000C0
    CRC : origin = 0x0000F0, length = 0x000002
    SECA: origin = 0x0000F2, length = 0x000002
    CODE : origin = 0x020000, length = 0x020000  /* DUMMY : origin = 0x020000, length = 0x020000 */
    FPRG: origin = 0x040000, length = 0x004000

    With the reduced code size and below linker command file updates the output file size is 264Kb


    MMR : origin = 0x000000, length = 0x0000C0
    CRC : origin = 0x0000F0, length = 0x000002
    SECA: origin = 0x0000F2, length = 0x000002
    DUMMY : origin = 0x020000, length = 0x020000 
    FPRG: origin = 0x040000, length = 0x004000  /* External SDRAM CE0 */
    CODE : origin = 0x044000, length = 0x020000 /* External SDRAM CE0 */

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    *(dummyCodeSecIOBuf+0x01FFFF) = (Uint16)0xBEEF;

    should be

    *(dummyCodeSecIOBuf+(Uint16 *)0x01FFFF) = (Uint16)0xBEEF;

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Prodigy 30 points

    Hi Ming,

    I'm getting similar error with the modified code. Also, I added ")" around the statement still having same errors.

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    Can you try the following:

    unsigned int *dummyCodeSecIOBuf;
    unsigned long offset;

    dummyCodeSecIOBuf = (unsigned int *)0x20000;
    offset = 0x1ffff;
    *(dummyCodeSecIOBuf+offset) = 0xBEEF;

    It works with C55x compiler.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Prodigy 30 points

    Hi Ming,

    Having same errors not sure why getting errors when you dont see it on the C55x compiler. I'm using C55x Compiler version Ti V3.3.2.

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    I was using the C55x CGT 4.4.1. I tested it with the SPRC133 C5509 example. It works too. Can you change to the CGT 4.4.1 and try again?

    Best regards,

    Ming 

  • 0 in reply to Ming Wei
    Prodigy 30 points

    I changed the C5500_4.4.1 compiler (ccsv6/tools/compiler/c5500_4.4.1/bin/cl55) and I'm seeing same error. Eventually I have to use CCS 3.3.2 as my project is a legacy one should use Compiler 3.3.2

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    Can you check your memory model is small or large or huge? Mine is small.

    Also what is your "type size to hold results of pointer math" in runtime memory model? Mine is 16. 

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Prodigy 30 points

    Hi Ming,

    I modified the Memory model from Large to Small and __ptrdiff_size from 32 to 16 still seeing similar errors. 

    Thanks,

    Ramesh G

  • 0 in reply to RAMESH GANESAMOORTHY
    TI__Guru 55345 points

    Hi Ramesh,

    I have no idea where it went wrong. Can you send your CCS project along with the source code and linker command file? In order to protect your intellectual property, you can simplify your code as much as possible. Also tell us your building environment, such as the DSP/BIOS version, CCS version CGT version etc.

    Best regards,

    Ming