IWRL6432: Memory Partition

Hi Luke,

Thanks for your guiding, I set the M4F_RAM : ORIGIN = 0x00400200 , LENGTH = 0x000BFE00 in linker.cmd,

I know it will build okay, but if try to place any thing to over the 512K boundary (0x80000), it will "not run" on CCS DEBUG, or physical EVM board.

for example,

assume we had done the modification of linker.cmd with extendsion 768KB,

try to do it on motion_detect.c around Line 2830:

void motion_detect(void* args)
{
//orgianal code above

#if 1
    volatile int *array;
    array = 0x480000;
    *array = 0;             //set breakpoint here for CCS DEBUG
    CLI_write("%d\r\n", *array);
#endif


//orginal code under
    /* Never return for this task. */
    SemaphoreP_pend(&gMmwMssMCB.demoInitTaskCompleteSemHandle, SystemP_WAIT_FOREVER);

    Board_driversClose();
    Drivers_close();
}

if debug step run and watch the " *array "value, debugger will report "Target failed to read 0x00480000"

then continue to go, will enter to the dead...

HWI_SECTION HwiP_hardFault_handler()
{
volatile uint32_t loop = 1;
while(loop)
;
}

this is the symptom of "It can not work".

I check my C:/ti/MMWAVE_L_SDK_05_01_00_04/docs/api_guide_xwrL64xx/TOOLS_BOOT.html

it mentioned about "Multi-core Image Gen",  and a paramter as:

• SH_MEM_CONFIG is 0

but no detail for it, do you think this is the point of entries...

I can't use the previous Gen1 radar rules to analogize the current practice,

[18xx/68xx] Shared memory alloc:
BSS|MSS TCMB|MSS TCMA|DSS

L6432 has no DSP, and mss is mono without TCMA, TCMB class...

Hi Brian, 

Give me some time to investigate further for you. I will get back to you Monday or Tuesday next week. I appreciate your patience.

Regards,
Luke

Hi Brian,

Just updating you, I am still currently working on this with our team. Thank you for your patience.

Regards,
Luke

Hi Brian, 

I apologize, your most recent response was deleted. Could you please repost your response? You should have a receipt of your response in your email and should be able to copy and paste it back here. 

Regards,
Luke

Also, I believe you were moving very much in the right direction. We just released a new version of the SDK, SDK 5.2, with an updated linker file which explicitly states that required RBL space. Could you apply your technique to the new SDK and see whether it works there?

Regards,
Luke

Hi Luke,

previous post was not so important anymore, I have check LSDK5.2, it solves most doubts, I think the linker.cmd of SDK5.2 is correct.

but a piece of 96KB that has not been explained.  Let's quick check current linker.cmd:

MEMORY
{
    M4F_VECS : ORIGIN = 0x00400000 , LENGTH = 0x00000200
    M4F_RAM12  : ORIGIN = 0x00400200 , LENGTH = (0x00058000 - 0x200) /* 32KB of RAM2 is being used by RBL */
    M4F_RBL    : ORIGIN = 0x00458000 , LENGTH = 0x8000 /* 32KB of RAM2 is being used by RBL */
    M4F_RAM3  : ORIGIN = 0x00460000 , LENGTH = 0x00020000
    HWASS_SHM_MEM : ORIGIN = 0x60000000, LENGTH = 0x00068000 /* 256KB in APPSS PD and 160KB in HWA PD */
}

Add each memory blocks length only 0xE8000(928KB), Compared with 1024KB, there is a shortage of 96KB.

Question:

Is the rest 96KB reserved to FECSS(cortex-M3) for debugging? otherwise, reserved by whom ?

I check "launch_iwrl6432.js" CCS in DEBUG will push the RFS firmware to "0x21208000", it seems a virtual address mapping to somewhere of phsical RAM. if the 96KB is reserved for RFS firmware in debugging, whether means if no need to use CCS debug mode, I can take the 96KB back to M4F_RAM3 partition.

I think I'm not the only one worrying about the remaining RAM.

I try to adopt LSDK5.2 case in advance.

our development is in progressing, not yet to implement MCAN & SPI service as planed, we just porting our service within UART, the remaining RAM has been quite critical.