• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 905 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/PROCESSOR-SDK-AM57X: Problems building and linking

Scott Jackson7
Intellectual 430 points
Part Number: PROCESSOR-SDK-AM57X
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

I'm working on a basic application to run on an IPU core that handles UART communications and then passes data to the main Linux OS via IPC. The IPU will be running SYS/BIOS. I have set up the following RTSC packages in CCS 7.1.0 (all from RTOS SDK 4.0.0.1):

  • EDMA3 v2.12.4
  • IPC 3.46.0.02
  • SYS/BIOS 6.46.5.55
  • am57xx PDK v1.0.7

I've set up my app.cfg, config.bld, etc. based on examples that come with the SDK.

I've also set up RTSC options as follows:

  • Target: ti.targets.arm.elf.M4
  • Platform: ti.platforms.evmDRA7XX:ipu1

If I use XDCtools 3.32.1.22, the build gets to the link step and then fails:

"configPkg/linker.cmd", line 246: error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".data" size 0x100138e . Available memory ranges:
EXT_DATA size: 0x200000 unused: 0x1fedb7 max hole: 0x1fedb7

I have no idea why the linker comes up with such a huge section size; I tried looking through the .map file that gets generated but it offers no help. I see a .data.1 section that is 0x01000018 bytes in length, but I have no idea what the linker is trying to place there; all I get is a "FAILED TO ALLOCATE" message, which obviously isn't very helpful. The module summary in the .map file is similarly unhelpful; it reports a "grand total" code size of 87978 bytes, ro data size of 21159 bytes, and rw data size of 484963 bytes, none of which even come close to the reported data section size.

For additional information, here's the offending part of the "SEGMENT ALLOCATION MAP"

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------

00000000    00000000    01000018   00000000    rw- .data.1

And my MEMORY CONFIGURATION:

        name            origin    length     used      unused    attr  fill
----------------------  --------  ---------  --------  --------  ----  --------

  L2_ROM                00000000   00004000  000005d0  00003a30  RWIX
  EXT_CODE              00004000   000fc000  00000000  000fc000  RW X
  L2_RAM                20000000   00010000  00000000  00010000  RWIX
  OCMC_RAM1             40300000   00080000  00000000  00080000  RWIX
  OCMC_RAM2             40400000   00100000  00000000  00100000  RWIX
  OCMC_RAM3             40500000   00100000  00000000  00100000  RWIX
  EXT_DATA              80000000   00200000  00088972  0017768e  RW  
  EXT_HEAP              80200000   00300000  00000000  00300000  RW  
  TRACE_BUF             9f000000   00060000  00008000  00058000  RW  
  EXC_DATA              9f060000   00010000  00000200  0000fe00  RW  
  PM_DATA               9f070000   00020000  00000000  00020000  RW X
 
Can anyone offer any advice as to how to determine what is trying to eat up so much memory?

  • 0
    Intellectual 430 points
    Further investigation indicates that I apparently included too much "stuff" in my app.cfg. As a result, XDCtools apparently tried to link in a huge amount of extra code to my executable. Notable things I took out were:

    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "evmAM572x";
    var Utils = xdc.loadPackage('ti.utils.profiling');
    var Mailbox = xdc.loadPackage('ti.sysbios.knl.mailbox');

    Most of these I'd included only because I saw an example somewhere include it. I have no idea what most XDCtools stuff does (and the error messages it generates usually aren't very helpful) but my experience is that any deviation from an example, either in code or in package version(s), causes failure, so I opted to include everything the examples did.

    Given how little my application code does and what BIOS packages I'm linking in, I'm still a little concerned that the map file reports over 100KB code usage and about 19KB of RO usage, but now I have a better idea of where I can look to try and reduce footprint.
  • 0 in reply to Scott Jackson7
    TI__Guru**** 393215 points
    Can we close this thread, or you need additional information?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 430 points

    Yes, please feel free to close it. That said if you have any additional information you'd like to provide, I'd certainly welcome it.