• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 1112 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.

malloc() errors with DDR heap and generating a CFG and linker script to avoid L2SRAM usage.

Philip Mucci
Prodigy 185 points
Other Parts Discussed in Thread: SYSBIOS

We're doing some work moving a library to use ECPY for DMA. As such, we're now integrated with SYSBIOS and the like. But we're having an issue with our malloc()'s failing. We are in need of a working CFG and Linker CMD file for simply building a binary that keeps everything out of L2SRAM and allows mallocs to run from DDR3. 

The thread follows below:

I am having a problem allocating arrays on the heap. Even though we
have fixed up linker.cmd to specify a heap, and point it at DDR3, when
I try to allocate arrays I get a message like this:
Starting alg process...
  A=00000000, B=00000000, C=00000000.
  ti.sysbios.heaps.HeapMem: line 294: out of memory:
handle=0x81943c, size=93320
  ti.sysbios.heaps.HeapMem: line 294: out of memory:
handle=0x81943c, size=93320
  ti.sysbios.heaps.HeapMem: line 294: out of memory:
handle=0x81943c, size=186632
When I look at that source, it is just the Error statement for being
out of memory.
I need to allocate the above arrays for my test of the kernel, from
the Heap 
I tried changing the parameters on the ".INTMEM_HEAP" section used
with fcConfig.cfg, that did not help matters. The -heap 0x0 was still
in linker.cmd.
I cannot proceed until I can allocate on the order of a few megabytes of
memory.
That was solved easy in the Bare Metal version, by pointing .sysmem at
DDR3 and setting -heap [sizeofDDR3].
I can't use the L2SRAM, or shared memory, I need the program space. I
have to use DDR3.
Can you help us figure out how to do that?
The example code does not seem to use malloc(), and I do not see in
the code anything that initializes the heap (but I saw routines that
do that in source). Should main.c be calling some heap_init() function
before I start trying to use malloc()?
One of the problems seems to be a whole list of sections being pointed

at L2SRAM, even if I change all of those in fcConfig.cfg to MSMCSRAM.

My kernels use L2SRAM by native address, I configure the L2 cache as
256K of L2SRAM (and 256K of cache), and my use of that space is not
using a SECTION at all.

If other sections are pointed at L2SRAM, then as soon as I load a
matrix into it I have overwritten those segments and the machine hangs
up.

Against my design, this config generates linker.cmd with
   .ti.decompress: load > L2SRAM
   .pinit: load >> L2SRAM
   .init_array: load > L2SRAM
   .data: load >> L2SRAM
   .sysmem: load > L2SRAM
   .args: load > L2SRAM align = 0x4, fill = 0 {_argsize = 0x200; }
   .ti.handler_table: load > L2SRAM

All of which I cannot see how to prevent. I need a way to NOT use
L2SRAM as the default destination for these Sections; My code is
optimized to use nearly every byte of the 256K L2SRAM area, there is
no room for guests.

In C6678_unified.cmd every section was pointed as MSMCSRAM, and I only
modified sysmem to point at DDR3. That is the development environment,
and what I need duplicated for the ECPY environment.

TC

  • 0
    TI__Mastermind 32475 points

    Which version of SYSBIOS, XDCTOOLS are you using?

    Its possible to manually place these output sections into DDR3 in your .cfg if you want to do that but the better solution would be to create your own platform that defaults the placement into the memory segment you want.

    To create your own customize platform see:  http://rtsc.eclipse.org/docs-tip/Demo_of_the_RTSC_Platform_Wizard_in_CCSv4

    Judah

  • 0 in reply to judahvang
    Prodigy 185 points

    We're using, bios_6_33_06_50, mcsdk_2_01_02_06 and xdctools_3_23_04_60 and running on the Advantech EVM. 

    We really don't want to create a custom platform. Is there a stock config and an example code that does malloc lying around?

  • 0
    TI__Mastermind 32475 points

    TC,

    Okay, I think there's a way you can do this through the .cfg file:

    1.  To place all your sections into DDR3, you need to do something like the following for each section in your program.

          For example:  Program.sectMap[".text"] = "DDR3";               // This will place .text >> DDR3

    2.  You can specify the heap size and the section with the following.  When you do malloc() it will take it from this section.

          var BIOS = xdc.useModule("ti.sysbios.BIOS");
          BIOS.heapSize = 0x10000;
          BIOS.heapSection = ".myHeapSection";

    Can you try this out?   I do recall there was an issue with malloc taking memory from the its own heap via -heap and not the BIIOS heap but I do not remember if that's in BIOS 6.33.06 or an older version.

    Judah

  • 0 in reply to judahvang
    Prodigy 185 points

    From TC

    --

    I already did that for the sections that were present; and the
    system hangs up or crashes. Including if I just redirect them to
    MSMCSRAM (where they were in our bare metal version).

    I gather Judah is saying I should add more such sections; which I
    could do, but something about just redirecting the *existing* sections
    caused sysbios to crash.

    I am not certain this is a necessary point still, I worked around it,
    so I could leave their L2SRAM sections in L2SRAM (I just moved my
    staging area 64K beyond the beginning of L2SRAM, and cut the part used
    for L2 Cache in half so I could still have 256K).

    I relocated one of the existing sections (.far) to point at DDR3
    instead of L2SRAM, and that (.far) section seems to be the one working
    their internal heap area.

    ----

    So we have a workaround, but we'd be curious as to the real solution.

  • 0 in reply to Philip Mucci
    TI__Mastermind 32475 points

    TC,

    Without knowing more about your program, its hard to say whether its okay to move something to DDR3 from L2SRAM.

    For example, are you running a single image on mulitple cores or just one core or multiple images on different cores?
    Depending on what your answer is, it would have a huge impact on whether a section can be placed in DDR3 or must remain in L2SRAM.

    Also with EDMA, you need to make sure to use global address and not local addresses as peripherals do not understand local addresses (I'm sure you are aware of this already).

    Judah

  • 0 in reply to judahvang
    Prodigy 185 points

    We are writing high performance library code that may be called by a single core or by multiple cores (on distinct data regions). 

  • 0 in reply to Philip Mucci
    TI__Mastermind 32475 points

    I can confirm that the heap goes into the .far section but its not the only thing that goes there.  I mean other things can go there too so its a bit dangerous to just point to the .far section but it sounds to me like you guys know what you are doing so I'm not going to worry about that.

    In general when running sysbios on multiple cores, you can place code and const data into shared memory (MSMCRAM or DDR) but data is required to be local unless each core is distinctively using its own Shared Memory.  Another words if you broke up shared memory so that each core has its own peice then you could place data there as well.

    Without more data on your crash its hard to say what's causing the crash.

    Judah