LAUNCHXL-F280049C: Memory Linking Error

Karthik,

Thanks for reaching out to the E2E forums.  Can you try to remove the RAMM0 from the .text:>> line?  I'd like to see what happens if we just allow the other sections to have RAMM0 and let the main code take the other Ram.  As you have noted there should be plenty of room for the main code in those RAMs without need for RAMM0.

Can you advise on the location/file where you made your code additions?  I would have assumed this would have increased the .text size only

Best,

Matthew

Dear Mathew,

Thanks a lot for the reply.

1) Following is the map file content before adding extra code.

................
name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
PAGE 0:
BEGIN 00000000 00000002 00000002 00000000 RWIX
RAMM0 000000f5 0000040b 0000040a 00000001 RWIX
RAMLS0 00008000 00000800 000007fc 00000004 RWIX
RAMLS1 00008800 00000800 000007fa 00000006 RWIX
RAMLS2 00009000 00000800 0000029e 00000562 RWIX
RAMLS3 00009800 00000800 00000000 00000800 RWIX
RAMLS4 0000a000 00000800 00000000 00000800 RWIX
RESET 003fffc0 00000002 00000000 00000002 RWIX

PAGE 1:
BOOT_RSVD 00000002 000000f3 00000000 000000f3 RWIX
RAMM1 00000500 00000300 00000200 00000100 RWIX
................

Its evident that RAMM0, RAMLS0 & RAMLS1 are fully consumed even without adding the new code. But as you told there is plenty of room for the main code in those RAMs without need for RAMM0. But I am not sure how to make use of that. Since RAM0 and RAM1 are TCM to CPU, whether it has better performance compared to others ?

2) Can you advise on the file/location where you made the code additions ?

Reply :- I have added the code in "Test1.c" which is my main application code file.

3) Can you try to remove the RAMM0 from the .text:>> line? I'd like to see what happens if we just allow the other sections to have RAMM0 and let the main code take the other Ram.

Reply :- Now the linker file definition is

.text : >> RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4, PAGE = 0

3.A) With the above modification, following is the memory map file content without adding extra code

PAGE 0:
BEGIN 00000000 00000002 00000002 00000000 RWIX
RAMM0 000000f5 0000040b 000003b6 00000055 RWIX
RAMLS0 00008000 00000800 00000800 00000000 RWIX
RAMLS1 00008800 00000800 000007fc 00000004 RWIX
RAMLS2 00009000 00000800 000002ec 00000514 RWIX
RAMLS3 00009800 00000800 00000000 00000800 RWIX
RAMLS4 0000a000 00000800 00000000 00000800 RWIX
RESET 003fffc0 00000002 00000000 00000002 RWIX

PAGE 1:
BOOT_RSVD 00000002 000000f3 00000000 000000f3 RWIX
RAMM1 00000500 00000300 00000200 00000100 RWIX

3.B) With the above modification, its still throwing errors. Following is the linker error with adding extra code

"../script_files/280048C_RAM_lnk.cmd", line 42: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment/blocking fails for section ".text" size 0x136cpage 0. Available memory ranges:
RAMLS0 size: 0x800 unused: 0x3 max hole: 0x3
RAMLS1 size: 0x800 unused: 0x4c7 max hole: 0x4c7
RAMLS2 size: 0x800 unused: 0x800 max hole: 0x800
RAMLS3 size: 0x800 unused: 0x800 max hole: 0x800
RAMLS4 size: 0x800 unused: 0x800 max hole: 0x800
error #10010: errors encountered during linking; "Test1.out" not built

Thanks and Regards
Karthik R

Karthik,

Can you take a look at this similar post(and then a link to some common issues).  Reading on this a bit I think there are some nuances with the linker.cmd syntax in how you we tell the linker to span multiple sections(or not).

We may need to manually group the individual memories into one for the linker.

All SRAMs on this device are 0 waitstate, so there will not be any performance hit vs using only M0/M1.

Best,

Matthew

Hi Mathew,

   Thanks for pointing out the thread. I have implemented as per the thread which specifies using the compiler option "--gen_func_subsections = on". I have added the same as follows

If you see my map files with "--gen_func_subsections = off" and with "--gen_func_subsections = on"

A) --gen_func_subsections = off

Query 1 :- In literature, it was mentioned that if we add "--gen_func_subsections = on", the code size should increase. But in this case it happended reverse.

Query 2 :- However when I added some more code, the same error is coming even with compiler option "--gen_func_subsections = on". In this case RAMS2 is not used at all.

   I am fully stuck here. 

Thanks and Regards

   Karthik R

Karthik,

For debug, can you replace the individual LS# blocks with one unified block like:

RAMLS : origin = 0x008000, length = 0x003000

And then replace the LS# with this block in the directives section.  

I want to understand better if the linker isn't understanding how to span sections.  BTW if this still fails I'd also try to use some of the GS RAMs(0xC000 - 0x13FFF) in the same way, those are much larger(and although not coupled to the CLA) it will at least tell us if we have a true code size issue.

Best,
Matthew

Thanks Karthik, I'm going to loop in some others on the team to better understand this.  From my reading of the C2000 tools, I don't think we should be seeing this issue.  

Best,

Matthew

Hi Matthew,

   Any update on this ?

      Thanks and Regards

          Karthik R

Karthik,

From what I've been able to find out this issue occurs when a function falls between two memory regions.  Even though a section like .text can be made up of multiple memory blocks, the linker won't place a function across a listed boundary.   

One solution is what we've discussed previously.  A potential downside is if you were placing data variables in the same physical block, then there would be stalls if the program were executing from that region.  However, as it is defined in your current linker files, all these memories are defined for program space so that wouldn't have been a concern anyway.

I'm following up on how we can make the linker error more intuitive to understand that this was the issue to begin with.

Best,
Matthew