Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hello François,

You are correct, the upper ~15MB is not configured by default. You can certainly add another section (we often do on projects here, called "DDR2") in the DSP/BIOS configuration on the project to utilize this block of memory of you like -- but it would in general be used only for the DSP.

Please note that in the most recent MDK we've added support in the libdsp (ARM) library to allow dynamic (DSP load time) configuration of the shared memory sections. This will allow you to modify the memory layout of the DSP/BIOS configuration in your DSP Code Composer Studio project anyway you like (e.g., increase POOL memory, etc.) and in your ARM application you can use the tcDspApp::SetSharedMemCfg() to let the ARM know where the relevant DSPLINK memory sections are. You can grab the code for that it you are not using the libdsp wrapper library and are using the DSPLINK library directly, and TI's wiki also describes how to do this. This will allow you to change you memory layout without rebuilding the dsplink kernel drivers and libraries.

Hope this helps...

-Mike

Mike,

I need the upper 15 MB memory region to store pre-calculated arrays to speed-up thing in real-time. Only the DSP need access to that data. Theses arrays are 8 MB big overall.

I tried to use the upper ~15 MB region by the "official" way: modifying platform.tci file and using pragma to force variable allocation to be in a specific memory segment. However, it is not working.

I modified mitydsp provided platform.tci file with the following modifications:

First, I added that part just after the mem_ext[0] section.

mem_ext[1] = {
    comment: "32Mbytes of the DSP's off-chip memory",
    name: "DDR2",
    base: 0xC7030000,
    len:  0xFD0000,
    space: "data" 
};

Second, I added that part after the POOLMEM section.

/*  ============================================================================
 *  MEM : DDR2
 *  ============================================================================
 */
var DDR2 = prog.module("MEM").instance("DDR2");
DDR2.base        = POOLMEM.base + POOLMEM.len ;
DDR2.len         = 0xFD0000 ;
DDR2.space        = "data";
DDR2.createHeap  = false;
DDR2.comment     = "DDR2";

Finally, in my code I use

#pragma DATA_ALIGN(my_var, 8);
#pragma DATA_SECTION(my_var, "DDR2");
int my_var[256][8192];

At link time, I got the following warning: "10247-D create output section DDR2 without SECTIONS". When I run my code, it crashes as soon I perform write to my_var. I do a "project clean" to be sure the generated linker file is re-generated. The map file of the executable shows the right memory configuration. I probably just missing a little detail but I don't know which one. Do you have idea? How do you access to that region of memory in your project?

Right now, I am able to use the upper 15 MB region by using physical memory addressing

int * my_array = (int *) 0xc7030000;

It seems to work fine but a little big ugly...

Thanks,

-François

To add the additional section in our projects, we typically modify the project ".tcf" file using the BIOS graphical editor and leave the plactform.tci file alone. Typically the .tcf file looks something like:

utils.loadPlatform("criticallink.platforms.MityDSP-L138");

/* The following DSP/BIOS Features are enabled.  */
bios.enableRealTimeAnalysis(prog);
bios.enableRtdx(prog);
bios.enableTskManager(prog);

bios.GBL.C64PLUSL2CFG = "256k";
bios.GBL.C64PLUSL2CFG = "64k";
bios.MEM.create("DDR_HIGH");
bios.MEM.instance("DDR_HIGH").comment = "More DDR Memory";
bios.MEM.instance("DDR_HIGH").len = 0x00a00000;
bios.MEM.instance("DDR_HIGH").createHeap = 0;
bios.MEM.instance("DDR_HIGH").base = 0xc7600000;
bios.MEM.instance("DDR_HIGH").comment = "More DDR (10 MB)";

Then we have found that we need at add an additional linker command file to force that section into existence, e.g., "link_add_ddr_high.cmd", that looks like the file below.

SECTIONS
{
    .data : DDR_HIGH > DDR_HIGH
}

Your code looks OK if it is "C" code. If it is "C++" code, the format of the pragma is different.

In truth, I've also run across some projects where our engineers have done the pointer hack you've done as well (with no problems, I might add). It is an embedded system after all... :^)

-Mike

Mike,

It was the additional linker file that was missing part of my side. When I added that file, no more linker warning and no more DSP application crash at start-up.

Thanks!

Maybe it will make sense to add information that we discussed here into this wiki page http://support.criticallink.com/redmine/projects/arm9-platforms/wiki/Cache_and_Memory?

Anyway, consider that ticket closed.

-François