Put large array in memory

Hi Matan,

Matan says said:

2.c. More generally, there are many different memory sections (.text, .stack, .bss, .cinit, .pinit, .const, .data, .switch, .sysmem, .far, .args, .cio, .vecs, xdc.meta). How do I know what each one mean and where it should be stored? where is this documented? 

In the compiler user guide ( http://www.ti.com/lit/ug/spru187u/spru187u.pdf) and the assembly language tool's user guide (http://www.ti.com/lit/ug/spru186s/spru186s.pdf) , the descriptions of these memory sections are documented. Please have a look at those.

 A sample linker command file is also given under section 5.3.6 in the compiler document.

 The format of the linker command file is described in the TMS320C6000 Assembly Language Tools User's Guide.

You may also find the below links useful

http://processors.wiki.ti.com/index.php/C28x_Compiler_-_Understanding_Linking#Types_of_Compiler_Sections

Regards,

Shankari

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

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

The memory name IRAM sounds like you are using DSP/BIOS. Moving your variable to DDR within the DSP/BIOS framework is difficult. I never found a way to do it properly. I found it was easier to define it outside BIOS with compiler and linker commands. Something like this:

File: big_array.c
#pragma DATA_SECTION(big_array, "big_array_section");
const float big_array[400000] =
{
  0.1,0.2,0.3,
  ...
};

File: big_array.cmd
SECTIONS
{
  big_array_section  :> SDRAM
}

The SDRAM memory region is defined somewhere in the many layers of tci and tcf files. Bare Metal (eg. StarterWare) are a lot simpler and direct but no OS niceties like threads, mutex, etc.

Hi Norman,

We are using SYS/BIOS.

We tried using compiler and linker commands like so:

File: big_array.c
#pragma DATA_SECTION(big_array, "big_array_section");
const float big_array[400000] =
{
  0.1,0.2,0.3,
  ...
};

File: big_array.cmd
SECTIONS
{
  big_array_section  :> DDR
}

But we encountered problems: The init of the array is a long text, so the .text memory section does not fit on to the IRAM. When we moved the .text section to the DDR as well, the program compiled and ran, but we had no audio output.

We tried moving just a function (using the CODE_SECTION pragma) that initialises the array to the DDR (instead of the entire .text), but then got an error - the .const section is to large for the IRAM. When we moved .const to the DDR, the program compiled and ran, but again there was no audio output.

So, as you see, we are walking in circles and would appreciate your help. How should we define the memory sections?

BTW, We thought of another solution - writing the init values to a binary file and then 'fread' it into the array at run time. Is that even possible when using the board?

Thanks for your help,

Matan

My experience was with large non-const data. For const data, I would have thought it would load the section like code; just once. I did not know that the compiler would use a .text. for init data. That just doubles the memory usage and adds a needless copy operation. Looking at the compiler manual, the PERSISTENT pragma might result in one copy, eg.

#pragma PERSISTENT (big_array);

Otherwise, I think you might have to resort to assembler to define your data. The lack of audio might be another problem unrelated to the DDR location. If it possible, maybe try scaling down the big array till you get audio.

I've only seen file operations used in the spi flash writer project. Never used it myself. That should work but that would mean your product is dependent upon a JTAG and CCS to be always connected. I find it amazing that the target can open a file on the host. I suspect such a solution would also be extremely slow.

You should unverify my post. Unverified threads attract more attention. You've reached the limit of my knowledge. Hopefully someone more knowledgable will comment.