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.

TMS320F28377D: CPU / CLA local shared RAM

Part Number: TMS320F28377D

In my cmd file I'm setting LS4 and LS5 as CLA program memory. All other LSRAM is data memory.

In the initialize CPU routine, when running from flash, there's a test RAM function. For every memory location in the input range the function stores the original value, then does a write and read, and then restores the original value. The function reports an error if there are locations that don't read back the written value. This function is used to check every location in LS0 - LS5. No errors are reported when the test RAM function is executed.

The test RAM function is called before configuring the CLA Memory and initializing the CLA. So all the memory is dedicated to CPU when test RAM runs.

I got a comment in a code review that CPU should not have write access to LS4-5 and that the test RAM function should only check LS0 - LS3 since LS4-LS5 is CLA program memory.

Maybe testing the RAM in this way is misleading relative to the cmd file contents, but is it safe for CPU to check LS4-5 in this way? Should CPU even have access to LS4-5 since it's designated as CLA program memory in the cmd file?

 

2837x_FLASH_lnk_cpu1.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
// The user must define CLA_C in the project linker settings if using the
// CLA C compiler
// Project Properties -> C2000 Linker -> Advanced Options -> Command File
// Preprocessing -> --define
#ifdef CLA_C
// Define a size for the CLA scratchpad area that will be used
// by the CLA compiler for local symbols and temps
// Also force references to the special symbols that mark the
// scratchpad are.
CLA_SCRATCHPAD_SIZE = 0x100;
--undef_sym=__cla_scratchpad_end
--undef_sym=__cla_scratchpad_start
#endif //CLA_C
MEMORY
{
PAGE 0 : /* Program Memory */
/* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
/* BEGIN is used for the "boot to Flash" bootloader mode */
BEGIN : origin = 0x080000, length = 0x000002
RAMM0 : origin = 0x000122, length = 0x0002DE
RAMD0 : origin = 0x00B000, length = 0x000800
// RAMLS4 : origin = 0x00A000, length = 0x000800
// RAMLS5 : origin = 0x00A800, length = 0x000800 // for CLA
RAMLS45 : origin = 0x00A000, length = 0x001000 // for CLA
// RAMGS0 : origin = 0x00C000, length = 0x001000
// RAMGS1 : origin = 0x00D000, length = 0x001000
RAMGS01 : origin = 0x00C000, length = 0x002000
RAMGS2 : origin = 0x00E000, length = 0x001000
RAMGS3 : origin = 0x00F000, length = 0x001000
//RAMGS14 : origin = 0x01A000, length = 0x001000 // for CPU2
//RAMGS15 : origin = 0x01B000, length = 0x001000 // for CPU2
RESET : origin = 0x3FFFC0, length = 0x000002
/* Flash sectors */
FLASHA : origin = 0x080002, length = 0x001FFE /* on-chip Flash */
FLASHB : origin = 0x082000, length = 0x002000 /* on-chip Flash */
FLASHC : origin = 0x084000, length = 0x002000 /* on-chip Flash */
FLASHD : origin = 0x086000, length = 0x002000 /* on-chip Flash */
FLASHE : origin = 0x088000, length = 0x008000 /* on-chip Flash */
FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
FLASHG : origin = 0x098000, length = 0x008000 /* on-chip Flash */
FLASHH : origin = 0x0A0000, length = 0x008000 /* on-chip Flash */
FLASHI : origin = 0x0A8000, length = 0x008000 /* on-chip Flash */
FLASHJ : origin = 0x0B0000, length = 0x008000 /* on-chip Flash */
FLASHK : origin = 0x0B8000, length = 0x002000 /* on-chip Flash */
FLASHL : origin = 0x0BA000, length = 0x002000 /* on-chip Flash */
FLASHM : origin = 0x0BC000, length = 0x002000 /* on-chip Flash */
FLASHN : origin = 0x0BE000, length = 0x002000 /* on-chip Flash */
PAGE 1 : /* Data Memory */
/* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */
BOOT_RSVD : origin = 0x000002, length = 0x000120 /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAMD1 : origin = 0x00B800, length = 0x000800
RAMLS0 : origin = 0x008000, length = 0x000800
RAMLS1 : origin = 0x008800, length = 0x000800
RAMLS2 : origin = 0x009000, length = 0x000800
RAMLS3 : origin = 0x009800, length = 0x000800
RAMGS4 : origin = 0x010000, length = 0x001000
RAMGS5 : origin = 0x011000, length = 0x001000
RAMGS6 : origin = 0x012000, length = 0x001000
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • rs said:
    The test RAM function is called before configuring the CLA Memory and initializing the CLA. So all the memory is dedicated to CPU when test RAM runs.

    rs said:
    Maybe testing the RAM in this way is misleading relative to the cmd file contents, but is it safe for CPU to check LS4-5 in this way? Should CPU even have access to LS4-5 since it's designated as CLA program memory in the cmd file?

    The .cmd file only tells the compiler and linker where you want code placed.  These tools don't know anything about the device and which memory you will configure to be accessible to which CPU and when.    As you mentioned, these blocks can be accessed by either the C28x or the CLA based on their configuration so accessing them with either is valid. 

  • Thanks Lori!