How to use external memory on the sam board.

Hello Thopman,

To address your query, here are some steps and resources that might help: 

1. Assigning Different segments on SHARC Audio module: You can explore CrossCore Embedded Studio (CCES) Help>Search> "specifying the memory map" for information on specifying the memory map. It provides detailed guidance on the default memory segments and sections for SHARC processors.
2. Accessing External Memory: For detailed information on accessing and configuring external memory, refer to the CCES manual, specifically section 2-217. This section provides comprehensive guidance on how to set up and use external memory in your application. It might be helpful to focus on sections related to memory allocation and linker scripts. (cces-SharcCompiler-manual.pdf)

Examples of assigning parts of code to different ram segments : 

1. Using #pragmadirectives to place variables in specific memory sections. For example:

#pragma section("seg_sdram")
float integer_delay_line[32];

This places the integer_delay_line array in the sdram (DDR) memory section.

2. Using __attribute__ syntax to specify memory segments and alignment. 

float integer_delay_line[32] __attribute__((section("seg_l1_block2"), aligned(8)));
void func(void) __attribute__ ((section("seg_l1_block2")));

This code places the integer_delay_line array in seg_l1_block2 section and ensures that is it aligned on an 8-byte boundary. Similar process can be done for defining function memory segments. 

Regards,

Aradhita

Hi Aradhita,

Thanks so much for your reply. In the meantime i've been doing a lot of reading in the manuals. But i still have a few questions of which i couldn't find a concise answer.

First of all the documentation eludes to but doesn't quite say it explicitly;
- If no directives are used in the code to assign memory. Will the mapped memory be filled by the linker from internal to (L1 first > L2 second) then it will fill external memory (if available)?
- Will it do so on a first come first served basis (so no particular order, unless directed by the user with directives)?
- Will the linker split the source automatically into data, zero-init data and code and map it to memory assigned to program data and code (if available) if this is not assigned by the user? Additionally if i assign a *.doj in the app.ldf to a #Object macro and assign that macro to a Input_section in the SECTIONS{...} Block like so

aSection
{
INPUT_SECTIONS($MY_OBJS_AND_LIBS(program))
} > MEM_L1_CODE

Will the code of said *.doj be assigned to that memory region? Or do i need to assign the code i want to be assigned with directives in the source code itself? if the latter is not needed can i still override the assignment with additional directives?

- In the default app.ldf (For a sam bare metal project) i only see 2 small sections in L1 memory for PM and DM and all the rest is BW type RAM. What is BW RAM (it's only mentioned once in the linker manual). And how does it differ from PM or DM RAM?

I'm sorry for the long list of additional questions. I'm still learning the platform. As a sidenote my modified faust code actually compiles. I think i broke the startup code/app.ldf by playing with the .svc app. When pasted into a fresh bare metal project it actually compiles.
Now it's time to actually test it.

Greetings,

Thomas

Hello Thomas,

Answering your questions below :

• The linker places frequently accessed data in L1 memory first, then uses L2 and L3 memory for less critical data to optimize performance. For code, you need to specify and label it as high priority. If you don’t, the linker treats all code equally and arranges it randomly.
• The compiler automatically splits source code into sections like code, initialized data, and zero-initialized data (BSS) in the object file, and linker maps them to memory based on priority and availability, without explicit directives from the user.
• Yes, if you assign a .doj file to a macro in the linker description file (LDF) and use that macro in an INPUT_SECTIONS directive within the SECTIONS block, the code from the .doj file will be assigned to the specified memory region. You don’t need to use directives in the source code for this assignment if it’s already specified in the LDF file. The linker will follow the LDF instructions to place the code in the designated memory region. But it’s advisable to avoid doing so unless you have a thorough understanding of Linker Description Files (LDF). Instead, it’s recommended to define memory segments directly in your source code using additional directives, such as #pragma directives or attributes.
• DM sections: Used for normal word data, PM sections: Used for normal word code.
  BW sections: Used for byte-addressed data, SW sections: Used for short word code.
  Legacy SHARC processors utilize word addressing, meaning they accessed memory using DM and PM sections. However, SHARC+ processors have shifted to byte processing, which involves using BW and SW sections. To ensure compatibility with both SHARC and SHARC+ processors, Linker Description Files (LDF) include all these sections.

You can generate a detailed XML map file of all objects and memory usage in your application, enable the ‘Generate Symbol Map’ option under the ‘General’ linker settings, and view it in any editor.

You can read the following for more information :

1. Description on modifying LDF files is explained in this note: ( Microsoft Word - Document2 ) The reading material focuses on the Blackfin processor, and the compilers for Blackfin and SHARC processors differ slightly. However, this material will provide you with a broad understanding of how to modify LDF files.
2. All of this information is covered by the Linker and Utilities Manual ( cces-LinkerUtilities-manual.pdf )

Regards,

Aradhita