• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 556 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.

L138: Different L1D cache/RAM allocation stops application running

Graham Bartlett
Intellectual 460 points
Other Parts Discussed in Thread: OMAP-L138, SYSBIOS

I'm using an OMAP-L138, with the DSP platform using SysBios.  I'm loading the DSP application onto the DSP using "slaveloader" from the ARM running Linux.  Both sides are using SysLink 2.21.03.11.

Up to now, we've been using a DSP platform configuration which has all 32K of L1D allocated to cache (the default setting).  We would like some variables to live in L1D for speed though, so I've been trying to change the L1D settings.  I've found that if I just change the platform configuration to L1D being split 16K cache and 16K RAM, the DSP application will not run.

I have made no changes to locations of any code/data, and the MAP file confirms that L1DSRAM is completely empty.  I think the code should just run - perhaps more slowly since it has less cache and has to do more swapping, but that should be all.  Does anyone have any ideas why this would happen?

I did experiment with this in the past when we flashed the DSP application into boot flash (as an AIS file) and ran it directly, and I don't remember seeing this.  Perhaps my memory is faulty (it was over a year ago), but is there anything relating to IPC or slaveloader which would be relevant?

  • 0
    TI__Mastermind 26780 points

    Graham,

    It seems like this “should just work”.  

    Can you please show the configuration changes you’ve made for L1D?  

    Also, which version of SYS/BIOS are you using?

    Thanks,
    Scott

  • 0 in reply to ScottG
    TI__Mastermind 22760 points

    Hi Graham,

    Can you try this with one of the Syslink examples, such as messageq?  You should just be able to modify the config.bld in ex02_messageq/shared, and change the l1DMode:

    Build.platformTable["ti.platforms.evmOMAPL138:dsp"] = {
        externalMemoryMap: [
            [ SR_0.name, SR_0 ],
            [ SR_1.name, SR_1 ],
            [ "DSP_PROG", {
                name: "DSP_PROG", space: "code/data", access: "RWX",
                base: 0xC3000000, len: 0x800000,
                comment: "DSP Program Memory (8 MB)"
            }]
        ],
        codeMemory:  "DSP_PROG",
        dataMemory:  "DSP_PROG",
        stackMemory: "DSP_PROG",
    //    l1DMode: "32k",
        l1DMode: "16k",
        l1PMode: "32k",
        l2Mode: "32k"
    };

    That should just work.

    Best regards,

        Janet

  • 0 in reply to ScottG
    Intellectual 460 points

    Scott, I'm using SYS/BIOS 6.35.4.50 (CCS 5.5.0), building under Linux.  Oh, also IPC 1.25.3.15, if that makes a difference (compatibility with SysLink?).

    The configuration change for L1D was purely changing the cache size in the RTSC platform wizard from 32K to 16K, then putting the code/data/stack locations back to the same place they were before (because the wizard loses them when you change memory details).  Nothing else changed.

    I'll check out the demos and see what happens.  Thanks for the tip on what to change, Janet.  Might be interesting to see whether that text file and whatever the platform wizard generates actually work the same.

  • 0 in reply to Graham Bartlett
    Intellectual 460 points

    Our BSP contractor gave us a modified version of the messageQ application which I could press into service, so I did a little tinkering to put some variables and stack in L1DSRAM (and checked the MAP file to make sure they did actually go there - I'm a natural sceptic).  This worked fine, so there clearly is no problem with SysLink, IPC or slaveloader generally loading and running stuff.

    It's not a completely apples-to-apples comparison though, because the demo code builds using a set of plain-text configuration/build files with a very vanilla debug configuration, whereas our actual application is all based around Code Composer Studio (Eclipse) and building in release mode with full optimisation.  An obvious next step is to set up a test project in CCS for the demo and see what happens when .

    Thanks for your help.  Maybe worth keeping this thread open until I've figured out what's going wrong?

  • 0 in reply to Graham Bartlett
    Intellectual 460 points

    Checking the test application, there were a couple of #defines different, so I added them.  I built the code, and it worked.

    Then I took the #defines out, and it still worked. 

    The build process was copying the source and CCS project to the "obj" directory for building.  Looks like there was some stale build file in the source directory which was getting copied across and wasn't then getting rebuilt from the new settings.  Insert your chosen profanity here...

    Anyway, looks like I'm in business.  Sorry for the false alarm.