CODECOMPOSER: CCS CMD File and gel files to fit larger code size

Sunny Ubergeek

Part Number: CODECOMPOSER
Other Parts Discussed in Thread: OMAP-L137

Hello,

Our code got too large for how the cmd file and gel files were configured, with error in CCS below, and configuration of cmd file below and gel file attached. When we tried to move .text and .far into the EMIFBSDRAM in the cmd file then when we start the CCS, the debugger cannot find main to stop at anymore. When we tried moving other sections, the debugger has a verification error. Can anyone explain in general how we can move the CCS code sections like .text and .far section to the larger memory in our memory map where the debugger can still find the main function (i.e., do certain sections always have to be together in the same memory map section)? Does this require modifying other files or the CCS debug configuration so the jtag can locate the code to single step through? Thank you again.

(error from CCS)

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, or the section contains padded functions. run placement with alignment fails for section ".far" size 0x2082c. Available memory ranges:
IRAM size: 0x40000 unused: 0x18a0c max hole: 0x18a0c

(cmd file configuration)

MEMORY
{
DSPL2ROM : org = 0x700000, len = 0x100000
DSPL2RAM : org = 0x800000, len = 0x40000
DSPL1PRAM : org = 0xe00000, len = 0x8000
DSPLDPRAM : org = 0xf00000, len = 0x8000
SHDSPL2ROM : org = 0x11700000, len = 0x100000
IRAM : org = 0x11800000, len = 0x40000
CACHE_L1P : org = 0x11e00000, len = 0x8000
CACHE_L1D : org = 0x11f00000, len = 0x8000
EMIFASDRAM : org = 0x40000000, len = 0x8000000
EMIFACS2 : org = 0x60000000, len = 0x2000000
EMIFACS3 : org = 0x62000000, len = 0x2000000
EMIFACS4 : org = 0x64000000, len = 0x2000000
EMIFACS5 : org = 0x66000000, len = 0x2000000
L3_CBA_RAM_ID : org = 0x80000000, len = 0x1000
L3_CBA_RAM_BL : org = 0x80001000, len = 0xf000
L3_CBA_RAM : org = 0x80010000, len = 0x10000
EMIFBSDRAM : org = 0xc0000000, len = 0x10000000
}

SECTIONS
{
.text: load > IRAM
.ti.decompress: load > IRAM
.stack: load > IRAM
GROUP: load > L3_CBA_RAM
{
.bss:
.neardata:
.rodata:
}
.cinit: load > L3_CBA_RAM
.pinit: load > L3_CBA_RAM
.init_array: load > IRAM
.const: load > L3_CBA_RAM
.data: load > IRAM
.fardata: load > IRAM
.switch: load > L3_CBA_RAM
.sysmem: load > IRAM
.far: load > IRAM
.args: load > IRAM align = 0x4, fill = 0 {_argsize = 0x0; }
.cio: load > L3_CBA_RAM
.ti.handler_table: load > IRAM
.c6xabi.exidx: load > IRAM
.c6xabi.extab: load > IRAM
.id: load > L3_CBA_RAM_ID
.clk: load > IRAM
.prd: load > IRAM
.swi: load > IRAM
.tsk: load > IRAM
.idl: load > IRAM
.idlcal: load > IRAM
.hwi_vec: load > IRAM
.sysdata: load > IRAM
.dsm: load > IRAM
.mem: load > IRAMfreertosdsp.gel
.bios: load > IRAM
.gio: load > IRAM
.sys: load > IRAM
.sysregs: load > IRAM
.gblinit: load > IRAM
.sysinit: load > IRAM
.trcdata: load > IRAM
.hwi: load > IRAM
.rtdx_text: load > IRAM
.TSK_idle$stk: load > IRAM
.LOG_system$buf: load > IRAM
.rtdx_data: load > IRAM
.hst1: load > IRAM
.hst0: load > IRAM
.trace: load > IRAM
.hst: load > IRAM
.log: load > IRAM
.pip: load > IRAM
.sts: load > IRAM
.heap: load > L3_CBA_RAM
.L3_CBA_RAM_ID: load > L3_CBA_RAM
.l3_cba_ram_bl: load > L3_CBA_RAM_BL
.L3_CBA_RAM$heap: load > L3_CBA_RAM
.printf: load > L3_CBA_RAM
.ppinfo: load > IRAM
.ppdata: load > IRAM
.binit: load > IRAM
.vecs: load > IRAM
.obj: load > IRAM

}

Thank you again.

3 months ago

0 Ki 3 months ago

TI__Guru**** 486841 points

Hello,

I brought this thread to the attention of the compiler experts who will be able to assist further.

Thanks

0 Paul Ouellette 3 months ago

TI__Prodigy 80 points

What TI CPU are you using?

0 Sunny Ubergeek 3 months ago in reply to Paul Ouellette

Intellectual 330 points

Hi Paul, Thank you. It is the OMAP-137 on the metal with our SW (no BIOS/TIRTOS) so we need to understand more about the TI cmd file in CCS, the compiler, etc. and debug configuration so we could move our growing code correctly to the larger RAM.

0 Anshu Madwesh 3 months ago in reply to Sunny Ubergeek

TI__Mastermind 24755 points

Hello,

Just to note, refer to this E2E FAQ on OMAP-L137: Notice regarding Processor SDK TI-RTOS for AM335x, AM437x, OMAP-L13x, C674x, K2G, AMIC110, AMIC120 devices

0 Mukul Bhatnagar 3 months ago in reply to Anshu Madwesh

TI__Guru* 86265 points

Sunny

Good to see you back again. As mentioned limited support on these devices. Here is an AI assisted response based on docs and past E2E search that may help you.

Fullscreen c6000_sdram_guide.html Download

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>TI C6000 DSP — Moving Code Sections to External Memory</title>
  <style>
    :root {
      --ti-red: #c00;
      --ti-blue: #0057a8;
      --ti-dark: #1a1a1a;
      --ti-gray: #f5f5f5;
      --ti-border: #ddd;
      --code-bg: #1e1e1e;
      --code-fg: #d4d4d4;
    }

    * { box-sizing: border-box; margin: 0; padding: 0; }

    body {
      font-family: 'Segoe UI', Arial, sans-serif;
      font-size: 14px;
      line-height: 1.6;
      color: var(--ti-dark);
      background: #fff;
      max-width: 960px;
      margin: 0 auto;
      padding: 32px 24px;
    }

    h1 {
      font-size: 22px;
      font-weight: 700;
      color: var(--ti-dark);
      border-bottom: 3px solid var(--ti-red);
      padding-bottom: 10px;
      margin-bottom: 24px;
    }

    h2 {
      font-size: 16px;
      font-weight: 700;
      color: #fff;
      background: var(--ti-blue);
      padding: 8px 14px;
      margin: 32px 0 14px;
      border-radius: 3px;
    }

    h2.red {
      background: var(--ti-red);
    }

    h3 {
      font-size: 14px;
      font-weight: 700;
      color: var(--ti-blue);
      margin: 18px 0 8px;
      border-left: 3px solid var(--ti-blue);
      padding-left: 8px;
    }

    p { margin-bottom: 10px; }

    a { color: var(--ti-blue); }

    blockquote {
      border-left: 4px solid var(--ti-red);
      background: #fff8f8;
      padding: 10px 16px;
      margin: 12px 0;
      font-style: normal;
    }

    blockquote.blue {
      border-left-color: var(--ti-blue);
      background: #f0f6ff;
    }

    code {
      font-family: 'Cascadia Code', 'Consolas', 'Courier New', monospace;
      font-size: 13px;
      background: #f0f0f0;
      padding: 1px 5px;
      border-radius: 3px;
      color: #c7254e;
    }

    pre {
      background: var(--code-bg);
      color: var(--code-fg);
      font-family: 'Cascadia Code', 'Consolas', 'Courier New', monospace;
      font-size: 13px;
      padding: 16px;
      border-radius: 4px;
      overflow-x: auto;
      margin: 12px 0;
      line-height: 1.5;
    }

    pre code {
      background: none;
      color: inherit;
      padding: 0;
      font-size: inherit;
    }

    table {
      width: 100%;
      border-collapse: collapse;
      margin: 14px 0;
      font-size: 13px;
    }

    thead tr {
      background: var(--ti-blue);
      color: #fff;
    }

    thead th {
      padding: 9px 12px;
      text-align: left;
      font-weight: 600;
    }

    tbody tr:nth-child(even) { background: var(--ti-gray); }
    tbody tr:hover { background: #e8f0fb; }

    tbody td {
      padding: 8px 12px;
      border-bottom: 1px solid var(--ti-border);
      vertical-align: top;
    }

    .badge {
      display: inline-block;
      font-size: 11px;
      font-weight: 700;
      padding: 2px 7px;
      border-radius: 3px;
      color: #fff;
    }

    .badge-green  { background: #2e7d32; }
    .badge-yellow { background: #f57c00; color: #fff; }
    .badge-red    { background: #c62828; }

    ul, ol {
      margin: 8px 0 10px 24px;
    }

    li { margin-bottom: 4px; }

    .checklist {
      list-style: none;
      margin-left: 0;
      font-family: 'Cascadia Code', 'Consolas', monospace;
      font-size: 13px;
      background: var(--code-bg);
      color: var(--code-fg);
      padding: 16px;
      border-radius: 4px;
    }

    .checklist li {
      padding: 3px 0;
    }

    .checklist li::before {
      content: "☐ ";
      color: #569cd6;
    }

    .summary-box {
      background: #fffbe6;
      border: 1px solid #ffe58f;
      border-left: 4px solid #faad14;
      padding: 14px 16px;
      border-radius: 3px;
      margin: 20px 0;
    }

    .summary-box strong { color: var(--ti-dark); }

    .section-intro {
      background: var(--ti-gray);
      border: 1px solid var(--ti-border);
      padding: 12px 16px;
      border-radius: 3px;
      margin-bottom: 20px;
    }

    .label-iram    { color: #2e7d32; font-weight: 700; }
    .label-sdram   { color: var(--ti-blue); font-weight: 700; }
    .label-warning { color: #e65100; font-weight: 700; }
  </style>
</head>
<body>

<h1>TI C6000 DSP &mdash; Moving Code Sections to External Memory (CCS / JTAG)</h1>

<!-- ===================== PROBLEM SUMMARY ===================== -->
<h2 class="red">1. The Core Problem &mdash; Summary</h2>

<p>
  Your <code>.far</code> section is <strong>0x2082C bytes (~130 KB)</strong> but only
  <strong>~0x18A0C (~99 KB)</strong> is free in IRAM. You need to move sections to
  <code>EMIFBSDRAM</code> (at <code>0xC0000000</code>). The challenges are:
</p>

<ol>
  <li><strong>Debugger can't find <code>main</code></strong> &rarr; EMIF SDRAM not initialized before code load</li>
  <li><strong>Verification error</strong> &rarr; JTAG trying to verify code in un-initialized SDRAM</li>
  <li><strong>Concern about which sections must stay together</strong></li>
</ol>

<!-- ===================== ROOT CAUSE ===================== -->
<h2>2. Root Cause &mdash; Why the Debugger Can't Find <code>main</code> in SDRAM</h2>

<blockquote>
  <strong>EMIFBSDRAM at <code>0xC0000000</code> is NOT self-initializing memory.</strong><br>
  Unlike IRAM (on-chip SRAM, always ready), external SDRAM must be configured by the EMIF
  controller before it is accessible. Until that happens, any attempt to load or run code there
  results in bus errors, verification failures, or &ldquo;can&rsquo;t find main.&rdquo;
</blockquote>

<p>When CCS connects via JTAG:</p>
<ol>
  <li>It <strong>resets the DSP</strong></li>
  <li>It tries to <strong>load your program</strong> (<code>.out</code> file sections) into their mapped addresses</li>
  <li>If <code>.text</code> is mapped to <code>0xC0000000</code> and EMIF/SDRAM is not yet initialized
      &rarr; <strong>bus error / can&rsquo;t find main</strong></li>
</ol>

<!-- ===================== GEL SOLUTION ===================== -->
<h2>3. The Standard Solution &mdash; GEL File EMIF Initialization</h2>

<blockquote class="blue">
  <strong>Your GEL file must initialize the EMIF controller and SDRAM <em>before</em> CCS loads the program.</strong>
</blockquote>

<p>
  In CCS, the GEL file is executed <strong>at connect time</strong>, before program load.
  You need to add or verify that your GEL file does the following:
</p>

<h3>GEL File Must Do (in <code>StartUp()</code> or a connected function)</h3>

<pre><code>StartUp()
{
    // Step 1: Tell CCS this memory exists and is R/W
    GEL_MapAdd(0xC0000000, 0, 0x10000000, 1, 1);

    // Step 2: Initialize EMIFB registers
    // (specific values depend on your board's SDRAM type/speed)
    *(int*)0x01800000 = 0x...;  // EMIFB SDRAM Control register
    *(int*)0x01800004 = 0x...;  // EMIFB SDRAM Timing register
    *(int*)0x01800008 = 0x...;  // EMIFB Refresh Control register

    // Step 3: (Optional) PLL/clock setup if not already done
}</code></pre>

<h3>Critical GEL Line</h3>
<pre><code>GEL_MapAdd(0xC0000000, 0, 0x10000000, 1, 1);</code></pre>
<p>
  This tells the <strong>CCS memory map</strong> that <code>0xC0000000</code>&ndash;<code>0xCFFFFFFF</code>
  (256 MB) is <strong>valid, readable, and writable</strong>. Without this, JTAG will not attempt
  to load or verify there.
</p>

<!-- ===================== CMD FILE ===================== -->
<h2>4. CMD File &mdash; How to Safely Move Sections</h2>

<h3>Recommended Section Migration Strategy</h3>

<table>
  <thead>
    <tr>
      <th>Section</th>
      <th>Can Move to EMIFBSDRAM?</th>
      <th>Notes</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>.text</code></td>
      <td><span class="badge badge-green">Yes (with caveats)</span></td>
      <td>Code runs slower from SDRAM; cache helps</td>
    </tr>
    <tr>
      <td><code>.far</code></td>
      <td><span class="badge badge-green">Yes — most common move</span></td>
      <td>Large data arrays, far-call data</td>
    </tr>
    <tr>
      <td><code>.fardata</code></td>
      <td><span class="badge badge-green">Yes</span></td>
      <td></td>
    </tr>
    <tr>
      <td><code>.const</code></td>
      <td><span class="badge badge-green">Yes</span></td>
      <td>Read-only constants</td>
    </tr>
    <tr>
      <td><code>.data</code></td>
      <td><span class="badge badge-green">Yes</span></td>
      <td>Initialized data</td>
    </tr>
    <tr>
      <td><code>.bss</code> / <code>.neardata</code></td>
      <td><span class="badge badge-yellow">Prefer keep near</span></td>
      <td>Near-data pointer assumptions</td>
    </tr>
    <tr>
      <td><code>.stack</code></td>
      <td><span class="badge badge-red">Keep in IRAM</span></td>
      <td>Stack must be accessible at boot before EMIF init</td>
    </tr>
    <tr>
      <td><code>.cinit</code></td>
      <td><span class="badge badge-yellow">Careful</span></td>
      <td>Used at C startup to init <code>.bss</code>/<code>.data</code> &mdash; must be accessible early</td>
    </tr>
    <tr>
      <td><code>.sysinit</code> / <code>.gblinit</code></td>
      <td><span class="badge badge-red">Keep in IRAM</span></td>
      <td>Boot-time init code runs before EMIF ready</td>
    </tr>
    <tr>
      <td><code>.vecs</code> / <code>.hwi_vec</code></td>
      <td><span class="badge badge-red">Keep in IRAM</span></td>
      <td>Interrupt vectors must be in fast, always-ready memory</td>
    </tr>
    <tr>
      <td><code>.rtdx_text</code></td>
      <td><span class="badge badge-red">Keep in IRAM</span></td>
      <td>JTAG RTDX communication</td>
    </tr>
  </tbody>
</table>

<h3>Suggested CMD File Changes</h3>

<pre><code>SECTIONS
{
    /* ---- KEEP IN IRAM (boot-critical, interrupt, JTAG) ---- */
    .text:             load > IRAM
    .stack:            load > IRAM
    .sysinit:          load > IRAM
    .gblinit:          load > IRAM
    .vecs:             load > IRAM
    .hwi_vec:          load > IRAM
    .hwi:              load > IRAM
    .rtdx_text:        load > IRAM
    .rtdx_data:        load > IRAM
    .ti.handler_table: load > IRAM
    .c6xabi.exidx:     load > IRAM
    .c6xabi.extab:     load > IRAM
    .binit:            load > IRAM
    .init_array:       load > IRAM
    .cinit:            load > IRAM   /* used at C startup */
    .ti.decompress:    load > IRAM

    /* ---- MOVE TO EMIFBSDRAM (large sections) ---- */
    .far:              load > EMIFBSDRAM   /* &lt;-- fixes your overflow */
    .fardata:          load > EMIFBSDRAM
    .const:            load > EMIFBSDRAM

    /* ---- Keep grouped in L3_CBA_RAM ---- */
    GROUP: load > L3_CBA_RAM
    {
        .bss:
        .neardata:
        .rodata:
    }
}</code></pre>

<!-- ===================== MOVING .TEXT ===================== -->
<h2>5. Moving <code>.text</code> &mdash; Special Considerations</h2>

<h3>Option A &mdash; Move ALL <code>.text</code> to EMIFBSDRAM</h3>
<pre><code>.text: load > EMIFBSDRAM</code></pre>
<ul>
  <li>Works <strong>if</strong> GEL initializes SDRAM before program load</li>
  <li><code>main</code> will be at an SDRAM address &mdash; CCS will find it after GEL runs</li>
  <li>Performance impact &mdash; use L1/L2 cache to mitigate</li>
</ul>

<h3>Option B &mdash; Split <code>.text</code> (Recommended for Performance)</h3>
<p>Keep critical/ISR code in IRAM; move bulk application code to SDRAM:</p>
<pre><code>/* Critical code stays in IRAM */
.text:cinit      load > IRAM
.text:_vectors   load > IRAM

/* Bulk application code in SDRAM */
.text            load > EMIFBSDRAM</code></pre>

<p>Or use <code>#pragma CODE_SECTION</code> in C to place specific functions:</p>
<pre><code>#pragma CODE_SECTION(myLargeFunction, ".text_sdram")</code></pre>
<p>Then in CMD:</p>
<pre><code>.text_sdram: load > EMIFBSDRAM</code></pre>

<!-- ===================== CCS DEBUG CONFIG ===================== -->
<h2>6. CCS Debug Configuration &mdash; What Needs to Change</h2>

<h3>In CCS Target Configuration (<code>.ccxml</code>)</h3>
<ol>
  <li>Confirm your GEL file is assigned to the DSP core</li>
  <li>Ensure <code>GEL_MapAdd()</code> covers the EMIFBSDRAM range</li>
  <li>Ensure EMIF init happens in <code>OnTargetConnect()</code> or <code>StartUp()</code></li>
</ol>

<h3>Memory Verification Errors</h3>
<p>
  If you get <strong>verification errors</strong>, CCS is trying to read back what it wrote to SDRAM
  but finds mismatches because SDRAM is not properly initialized:
</p>
<ul>
  <li>Go to: <strong>Debug &rarr; Debug Configurations &rarr; Target &rarr; Program/Memory Load Options</strong></li>
  <li>Uncheck <strong>&ldquo;Perform memory verification&rdquo;</strong> temporarily to test</li>
  <li>Once GEL init works, re-enable it</li>
</ul>

<!-- ===================== CACHE ===================== -->
<h2>7. Enabling Cache &mdash; Essential for SDRAM Code Performance</h2>

<p>If you move <code>.text</code> to SDRAM, enable L1P/L2 cache so the DSP caches instructions:</p>

<pre><code>// Set Memory Attribute Register for EMIFBSDRAM range (0xC0000000)
// MAR192 — cacheable, prefetchable
*(unsigned int*)0x01848380 = 0x0F;</code></pre>

<p>Or in CCS: <strong>Target &rarr; Memory Browser &rarr; Configure Cache</strong></p>

<!-- ===================== CHECKLIST ===================== -->
<h2>8. Complete Checklist for Success</h2>

<ul class="checklist">
  <li>1. GEL file: Add <code>GEL_MapAdd()</code> for EMIFBSDRAM range</li>
  <li>2. GEL file: Initialize EMIFB controller registers for your SDRAM</li>
  <li>3. GEL file: Ensure this runs at <code>OnTargetConnect()</code> BEFORE program load</li>
  <li>4. CMD file: Move <code>.far</code> and <code>.fardata</code> to EMIFBSDRAM (immediate fix)</li>
  <li>5. CMD file: Optionally move <code>.text</code> to EMIFBSDRAM (more space)</li>
  <li>6. CMD file: Keep <code>.stack</code>, <code>.vecs</code>, <code>.hwi_vec</code>, <code>.sysinit</code> in IRAM</li>
  <li>7. CCS: Temporarily disable memory verification to test SDRAM load</li>
  <li>8. CCS: Enable L2 cache MAR registers for SDRAM range for performance</li>
  <li>9. Test: Set breakpoint at <code>main()</code>, confirm CCS hits it</li>
  <li>10. Re-enable memory verification once stable</li>
</ul>

<!-- ===================== KEY TAKEAWAY TABLE ===================== -->
<h2>9. Key Takeaway Table</h2>

<table>
  <thead>
    <tr>
      <th>Question</th>
      <th>Answer</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Do sections have to be together?</td>
      <td>No &mdash; sections can be in any memory region independently</td>
    </tr>
    <tr>
      <td>Why can't debugger find <code>main</code> in SDRAM?</td>
      <td>SDRAM not initialized before JTAG loads code</td>
    </tr>
    <tr>
      <td>Fix is in which file?</td>
      <td><strong>GEL file</strong> (EMIF init + <code>GEL_MapAdd</code>)</td>
    </tr>
    <tr>
      <td>What sections MUST stay in IRAM?</td>
      <td><code>.stack</code>, <code>.vecs</code>, <code>.hwi_vec</code>, <code>.sysinit</code>, RTDX sections</td>
    </tr>
    <tr>
      <td>Can <code>.far</code> safely move to EMIFBSDRAM?</td>
      <td><span class="badge badge-green">Yes</span> &mdash; this is the standard solution</td>
    </tr>
    <tr>
      <td>Can <code>.text</code> move to EMIFBSDRAM?</td>
      <td><span class="badge badge-green">Yes</span> &mdash; after GEL fix; use cache for performance</td>
    </tr>
    <tr>
      <td>Verification error cause?</td>
      <td>JTAG reading back from uninitialized SDRAM</td>
    </tr>
  </tbody>
</table>

<!-- ===================== FINAL SUMMARY ===================== -->
<div class="summary-box">
  <strong>The single most important fix:</strong> Make sure your <strong>GEL file initializes the EMIF-B
  controller and calls <code>GEL_MapAdd(0xC0000000, ...)</code> before CCS loads the program.</strong>
  Once that is working, moving <code>.far</code> (and optionally <code>.text</code>) to
  <code>EMIFBSDRAM</code> in the CMD file will work perfectly and the debugger will find
  <code>main</code> without issues.
</div>

</body>
</html>

0 Sunny Ubergeek 3 months ago in reply to Mukul Bhatnagar

Intellectual 330 points

Hi Mukul,

Thank you.We are not using TI-RTOS or Bios (see original post above).

We understood that there was no support for BIOS/TI-RTOS (which is why we are not using BIOS/TI-RTOS and our own software), but that OMAP-137 was still supported and there were no plans to obsolete it (that there were no plans to discontinue production for OMAPL137). Has this changed? That is why we kept using OMAP-137.

Anyhow, regardless please forgive the confusion -- to clarify -- my questions were trying to understand the TI compiler, debug configuration, CCS projects, gel files, and with the cmd files in general (they are not only used with OMAP-137 projects, but I have used them with our other CCS projects using the RM42 and Tiva on our other products):

- regardless of processor, in TI cmd files, do certain sections always have to be together in the same memory map section in these cmd files so we have to move them together?

- regardless of processor, can you explain in general how we can move the CCS code sections like .text and .far section to the larger memory in our memory map where the debugger can still find the main function? what is it that allows debug config to locate and start at "main" after we start the debugger.

- regardless of processor, does this require modifying other files (like a gel file) or the CCS debug configuration so the jtag can locate the code to single step through?

Thank you again.

0 Sunny Ubergeek 3 months ago in reply to Anshu Madwesh

Intellectual 330 points

Hello Anshu,

Thank you.We are not using TI-RTOS or Bios (see original post above).

Anyhow, regardless please forgive the confusion -- to clarify -- my questions were trying to understand the TI compiler, debug configuration, CCS projects, gel files, and with the cmd files in general (they are not only used with OMAP-137 projects, but I have used them with our projects using the RM42 and Tiva on our other products):

- regardless of processor, in TI cmd files, do certain sections always have to be together in the same memory map section in these cmd files so we have to move them together?

- regardless of processor, does this require modifying other files (like the gel file) or the CCS debug configuration so the jtag can locate the code to single step through?

Thank you again.

0 Sunny Ubergeek 3 months ago in reply to Ki

Intellectual 330 points

Thank you Ki. I think there was a misunderstanding below, my questions were not TI-RTOS related at all (we are not using TI-RTOS) or processor specific about how to understand how to modify the CCS compiler, command file sections, gel files, etc. Or is everyone out for summer holiday and just give them more time to respond?

Code Composer Studio™︎

Code Composer Studio forum

CODECOMPOSER: CCS CMD File and gel files to fit larger code size