• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 43273 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

error #10099-D: program will not fit into available memory

Zvi Vered
Expert 1990 points
Other Parts Discussed in Thread: CONTROLSUITE

Hello,

I built a very simple application for TMSF28335 using Code Composer 5.2.0.00069.

I created an empty project for this DSP and used 28335_RAM_lnk.cmd with no changes.

The code is:

#include "stdio.h"

int main (void)

{

   int x;

   printf ("Hello\n"); 

}

Upon end of build I got the following error:

"C:/tidcs/c28/DSP2833x/v131/DSP2833x_common/cmd/28335_RAM_lnk.cmd", line 125: error #10099-D: program will not fit into available memory.  placement with alignment/blocking fails for section ".text" size 0x18f5 page 0.  Available memory ranges:

   RAML1        size: 0x1000       unused: 0x1000       max hole: 0x1000   

error #10010: errors encountered during linking; "Image.out" not built

gmake: *** [Image.out] Error 1

gmake: Target `all' not remade because of errors.

**** Build Finished ****

According to map file:

output                                  attributes/

section   page    origin      length       input sections

--------  ----  ----------  ----------   ----------------

.text      0    00000000    000018f6     FAILED TO ALLOCATE

.pinit     0    00008000    00000000     UNINITIALIZED

....

But accordind to the cmd file:

   codestart        : > BEGIN,    PAGE = 0

   ramfuncs         : > RAML0,    PAGE = 0

.text            : > RAML1,     PAGE = 0

.cinit           : > RAML0,     PAGE = 0

.....

The .text region consumes 0x1816 bytes but it is defined: > RAML1

So the maximum available size is: 0x1000 x 3 = 0x4000 bytes

   RAML0      : origin = 0x008000, length = 0x001000

   RAML1      : origin = 0x009000, length = 0x001000

   RAML2      : origin = 0x00A000, length = 0x001000

   RAML3      : origin = 0x00B000, length = 0x001000

What is the reason linker can not place .text at areas higher than 0x9000 ?

Thanks,

Zvika

  • 0
    Expert 1990 points

    Hello,

    I fixed the cmd ffile and wrote:

    RAML1      : origin = 0x009000, length = 0x002000

    /*RAML2      : origin = 0x00A000, length = 0x001000 */

    RAML3      : origin = 0x00B000, length = 0x001000

    This way the build is OK.

    Is it the right way ?

    Thanks,

    Zvika

      

  • 0
    TI__Guru**** 173310 points

    Zvika,

    As you already inferred, the reason for the error is that "printf" code is large and takes up a large amount of memory which is not available in the way the default linker command file, 28335_RAM_lnk.cmd is set up. Please see the note related to such errors here (it is written for F281x but the same applies for F28335x): http://processors.wiki.ti.com/index.php/C2000_Getting_Started_with_Code_Composer_Studio_v4#Errors_with_.22hello_world.22_project_using_F281x_Devices

    In this case, it is fine to adjust the linker command file the way you have done, as those RAM memory regions are just contiguous.

    For future though, if you are new to the device and are trying out simple programs to get started,  I would recommend starting with the examples in ControlSuite software for C2000, as these are all set up to work out of the box.

  • 0 in reply to Zvi Vered
    TI__Guru**** 168317 points

    Zvika,

    Just adding to Aarti's reply, another alternative is to split the .text memory section into multiple memory regions. Check the forum thread below:

    http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/215845/761954.aspx#761954

    All that said, never lose the focus on the hardware when doing these modifications, as the linker will do whatever it is told so.

    Certain devices allow for faster simultaneous memory access when data is split between two regions and, in the case of the F28355, some of the RAM memory regions are accessible by the DMA and some aren't.

    Hope this helps,

    Rafael

  • 0 in reply to Zvi Vered
    Prodigy 180 points

    Here is my first communications with TI in eight years:

    I used the old Code Composer until 2005, creating products for the LF2407A. Come 2013, and I am brought back for a re-do, this time using the F28069. The task is roughly the same, but the new part is twice as fast, and has vastly more FLASH and RAM. The present hardware is the USB EMU board into which is populated with an F28069 ControlCARD, the present software is Code Composer Studio 5.4.0.00091, the compiler version is TI v6.1.0, the effective compiler version is TI v6.1.3, and I pulled in the updates.

    I started with the Example_2806xCpuTimer, and made some changes to the timing, GPIO use, etc., and all was well. I received some messages about XDIAS, looked in the forums, and see that whatever it is, it is mostly a nuisance. My oscilloscope showed that it was working fine (with one minor exception). I then took my old code from 2005 (which when built for the little LF2407A, fit with room to spare), updated the GPIOs to work with the new part, and glued it to my Example_2806xCpuTimer project. Sadly, the attempt to build it ended with the following:

    "C:/ti/controlSUITE/device_support/f2806x/v130/F2806x_common/cmd/28069_RAM_lnk.cmd", line 112: error:
    program will not fit into available memory. placement with
    alignment/blocking fails for section ".cinit" size 0x4ed page 0. Available
    memory ranges:
    RAMM0 size: 0x3b0 unused: 0x391 max hole: 0x391
    .cinit : > RAMM0, PAGE = 0
    warning: entry-point symbol other than "_c_int00" specified: "code_start"

    error: errors encountered during linking; "Example_2806xCpuTimer.out" not
    >> Compilation failure
    built
    gmake: *** [Example_2806xCpuTimer.out] Error 1
    gmake: Target `all' not remade because of errors.

    **** Build Finished ****

    The linker command file was 28069_RAM_lnk.cmd, so I tried F28069.cmd, but that resulted in many errors, so I backtracked to the 28069_RAM_lnk.cmd file, to which I have not made any changes. This file contains (among other things):

    PAGE 0 : /* Program Memory */
    RAML0 : origin = 0x008000, length = 0x000800 /* on-chip RAM block L0 */
    RAML1 : origin = 0x008800, length = 0x000400 /* on-chip RAM block L1 */
    OTP : origin = 0x3D7800, length = 0x000400 /* on-chip OTP */

    FLASHH : origin = 0x3D8000, length = 0x004000 /* on-chip FLASH */

    And:

    PAGE 1 : /* Data Memory */
    BOOT_RSVD : origin = 0x000000, length = 0x000050 /* Part of M0, BOOT rom will use this for stack */
    RAMM0 : origin = 0x000050, length = 0x0003B0 /* on-chip RAM block M0 */
    RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
    RAML2 : origin = 0x008C00, length = 0x000400 /* on-chip RAM block L2 */
    RAML3 : origin = 0x009000, length = 0x001000 /* on-chip RAM block L3 */
    RAML4 : origin = 0x00A000, length = 0x002000 /* on-chip RAM block L4 */

    And:

    .cinit : > FLASHA, PAGE = 0
    .pinit : > FLASHA, PAGE = 0
    .text : > FLASHA, PAGE = 0
    codestart : > BEGIN, PAGE = 0

    And:

    .stack : > RAMM0, PAGE = 1
    .ebss : > RAML2, PAGE = 1
    .esysmem : > RAML2, PAGE = 1

    The resultant map file contained (among other things):

    PAGE 0:
    BEGIN 00000000 00000002 00000002 00000000 RWIX
    RAMM0 00000050 000003b0 0000001f 00000391 RWIX
    RAML0_L3 00008000 00002000 000018d0 00000730 RWIXAnd:

    And:

    output attributes/
    section page origin length input sections
    -------- ---- ---------- ---------- ----------------
    codestart
    * 0 00000000 00000002
    00000000 00000002 F2806x_CodeStartBranch.obj (codestart)

    .cinit 0 00000000 000004ed FAILED TO ALLOCATE
    .pinit 0 00000050 00000000 UNINITIALIZED

    ramfuncs 0 00000050 0000001f
    00000050 0000001b F2806x_SysCtrl.obj (ramfuncs)
    0000006b 00000004 F2806x_usDelay.obj (ramfuncs)

    .text 0 00008000 000018d0

    My problem appears to be very similar to that of Zvi Vered, but I don't yet know the memory map of the F28069 inside and out like I did the LF2407A, and am unsure exactly how to address (no pun intended) the problem. The .cmd file's .cinit points to PAGE 0's FLASHA, which has a length of 0x3F80, yet the .map file reports that the .cinit is only 0x4ED in size, so why does it fail? I also don't understand why the .map file makes a reference here to RAMM0 because the .cmd file's .stack points there. The .map file is very unclear; what exactly is failing? I noticed that the .cmd file shows the RAM to be in PAGE 1, but the .map file shows it to be in PAGE 0. What is going on there? Further down in the .map file, I do see plenty of the .text content in the expected location.

    Zvika found a solution that involved editing the .cmd file, but it is unclear whether that it done through a facility within CCS, or is done "behind its back" using a simple text editor. How should I do this for my project that uses the F28069? Is there a tutorial somewhere that explains how to deal with such problems? I didn't glean enough from the links that you and another provided. Please advise!

    Finally, back in the old days of Code Composer, it was a real headache to migrate from a project with the code running from RAM to one running from FLASH, so once we got it working from FLASH, we just left it there, kept Vpp pulled high, and were perfectly content with the time needed to FLASH new code into the chip. Today, how do we choose between the two, and is there any harm to the previous approach? It looks like .cinit already goes to the FLASH!

    Thanks -- Mark

    P.S. I don't know whether or not it is noteworthy, but there are a variety of XDIAS-related warnings such as "Invalid project path: Include path not found (\packages\ti\xdias)" and I am wondering if that is of concern, and how to resolve it. I am hoping that the warnings are just noise as suggested elsewhere (in the forum) and that they can be ignored, but it can be dangerous to ignore warnings without fully understanding them.

  • 0 in reply to Mark Walsh1
    Prodigy 180 points

    I never heard back from TI, so I set about manually editing the .map file.  I had absolutely no luck at all, and then I wondered if CCS was even reading my .map file, so I put garbage right in the middle of it, and the tools did not complain.  As it turned out, even though I had imported the project to my workspace and the .map file was put into my workspace, the project's setting for the .map file location was somehow not updated during the import!  Changing that setting to my .map file took care of it, and all was well (until I got to the next CCS issue).