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.

DSP/BIOS 6 linker

Other Parts Discussed in Thread: SYSBIOS

I'm using DSP/BIOS 6.20, CCSv4.1, and XDC 3.16 with an ezdsp28335.  I'm trying to map the .transferBufferSection to my SRAM by putting an override in my .cfg file.  However, it does not matter what I do, it keeps assigning the transfer buffer to FLASH, which is obviously not a good idea.  Here's the line I'm putting in my .cfg file:

Program.sectMap[".transferBufferSection"] = "SRAM";

I've even tried a loadSegment and runSegment setting such as:

var TxBufSect = new Program.SectionSpec;

TxBufSect.runSegment = "SRAM";

TxBufSect.loadSegment = "FLASHA";

Program.sectMap[".transferBufferSection"] = TxBufSect;

to no avail.  Is there a particular reason the process that generates the linker command file won't pick this up?  It picks up every other re-mapping I apply.

Thanks,

Mark Takatz

 

 

  • Mark,

    I'm going to move this to the DSP/BIOS forum so they can help.

    -Lori

  • Hi Mark,

    What RTSC platform are you using in building your application? You should see a generated linker command file - 'linker.cmd' -  in the 'Debug/configPkg' folder of your RTSC configuration project. If the configuration is done correctly you should see a statement like

    SECTIONS

    {

    ....................

      .transferBufferSection: load >> SRAM PAGE 0

    ....................

     }

    Is it possible for you to attach your CCS4 project(s) to this post? You can go to the "Options" tab and select the "Add/Update" button.

     

    Regards

    Amit

  • CCSv4.1 with DSP/BIOS 6.20 and XDC tools version 3.16.  The linker command file always has the line:

    .transferBufferSection: load >> FLASHA PAGE 1

    where FLASHA is the override for "data" in my platform designation.  I used the exact code as described above. 

    There are other oddities with the linker as well.  I cannot extract load and run addresses from the configuration script in order to do a copy from FLASH to RAM, so I have to include my own linker file to utilize the LOAD_START and similar macros.  After including this linker command file (which does not currently contain a reference to .transferBufferSection), I end up with two .cinit, .pinit, and .const sections.  One of each has the proper RUN ADDR designation (and loaded into FLASH), and the other is listed in FLASH as UNINITIALIZED.

    Is there a way to upload my project in a manner that nobody else can access it?

    Mark

  • >Is there a way to upload my project in a manner that nobody else can access it?

    Mark,

    I think the attachments to a forum post can be viewed by everyone. Is it possible to make a barebones project without any proprietary code  that reproduces the problem?

    Thanks

    Amit

  • Yup.  I've also attached the platform I'm using.  I put the platform directly into the ti/platforms directory, i.e., $CCS_INSTALL\xdctools_3_16_03_36\packages\ti\platforms\DSP_Board_v41.

    Mark

    DSP_Board_v41.zip
  • Looks like I can only attach one at a time.  This one contains the platform.

    Mark

    ti_platforms_DSP_Board_v41.zip
  • Hi Mark,

    The 'ti.sysbios.rta.Agent' module of SYS/BIOS places the '.transferBufferSection'  in the RTSC platform's data memory.

    Consider the following code fragment from ti/sysbios/rta/Agent.xs:

    function allocateTxBuffers(mod)

    {

        /* Place transferBufferSection into platform's dataMemory */

        if (Agent.transferBufferSection == ".transferBufferSection") {

            Program.sectMap[".transferBufferSection"] = new Program.SectionSpec(

                {loadSegment: Program.platform.dataMemory});

        }

    ...

    }

     

    Since the data memory of your platform is set to "FLASHA" this setting overrides your setting in the configuration file. Setting the 'dataMemory'  property of your platform to "SRAM" should address this problem. I am not sure if this usage is documented any where. Maybe someone from the BIOS team can jump in here and clarify  the usage of 'ti.sysbios.rta.Agent'.

     

    Regards

    Amit

     

  • Gotcha.

    There's a serious problem with the way the XDC tools handle all of the memory.  Things are forced into "code" and "data," with only one override for which section applies to each.  This causes problems when trying to boot to FLASH, but run from RAM.  This is why I was using FLASHA instead of SRAM as my default (which ultimately did not help).

    Thanks,

    Mark Takatz