Linker error

A program for the 6416 that compiles in code composer 3.1 without error in
debug mode fails to link in release mode, giving errors like this:

error: memory types ISRAM and ISRAM on page 0 overlap

along with lots of warnings of this type:

async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
named '.trace'

These values are being set up in the .cdb file for the project, and code
composer is writing a cfg.cmd file for the project, and as near as I can tell
the linker is trying to use both files and getting confused.

How should I handle this?
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Hi jim,

Can you share the cmd file to analyze the Section instructions.

Regards,

Narendra

________________________________

From: c... [mailto:c...] On Behalf Of jim
Sent: Wednesday, February 27, 2008 1:03 AM
To: c...
Subject: [c6x] Linker error

A program for the 6416 that compiles in code composer 3.1 without error
in
debug mode fails to link in release mode, giving errors like this:

error: memory types ISRAM and ISRAM on page 0 overlap

along with lots of warnings of this type:

async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
named '.trace'

These values are being set up in the .cdb file for the project, and code

composer is writing a cfg.cmd file for the project, and as near as I can
tell
the linker is trying to use both files and getting confused.

How should I handle this?

SASKEN BUSINESS DISCLAIMER
-------------------------
This message may contain confidential, proprietary or legally privileged information. In
case you are not the original intended Recipient of the message, you must not, directly or
indirectly, use, Disclose, distribute, print, or copy any part of this message and you are
requested to delete it and inform the sender. Any views expressed in this message are
those of the individual sender unless otherwise stated. Nothing contained in this message
shall be construed as an offer or acceptance of any offer by Sasken Communication
Technologies Limited ("Sasken") unless sent with that express intent and with due
authority of Sasken. Sasken has taken enough precautions to prevent the spread of
viruses. However the company accepts no liability for any damage caused by any virus
transmitted by this email Start a New Thread

Attached

On Wednesday 27 February 2008 11:48:12 you wrote:
> Hi jim,
>
> Can you share the cmd file to analyze the Section instructions.
>
> Regards,
>
> Narendra
>
> ________________________________
>
> From: c... [mailto:c...] On Behalf Of jim
> Sent: Wednesday, February 27, 2008 1:03 AM
> To: c...
> Subject: [c6x] Linker error
>
> A program for the 6416 that compiles in code composer 3.1 without error
> in
> debug mode fails to link in release mode, giving errors like this:
>
> error: memory types ISRAM and ISRAM on page 0 overlap
>
> along with lots of warnings of this type:
>
> async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> named '.trace'
>
> These values are being set up in the .cdb file for the project, and code
>
> composer is writing a cfg.cmd file for the project, and as near as I can
> tell
> the linker is trying to use both files and getting confused.
>
> How should I handle this?
>
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Jim,

On Tue, Feb 26, 2008 at 1:33 PM, jim wrote:

> A program for the 6416 that compiles in code composer 3.1 without error in
> debug mode fails to link in release mode, giving errors like this:
>
> error: memory types ISRAM and ISRAM on page 0 overlap
>
> along with lots of warnings of this type:
>
> async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> named '.trace'
>
> These values are being set up in the .cdb file for the project, and code
> composer is writing a cfg.cmd file for the project, and as near as I can
> tell
> the linker is trying to use both files and getting confused.
>
> How should I handle this?

Have you looked at the differences in the in the cfg.cmd files
generated in debug vs. release mode?? mainly the instances of '.trace'

mikedunn
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Jim,

This list does not allow attachments.
Just cut and paste into a email body

R. Williams
---------- Original Message -----------
From: jim
To: "Narendra Lakshman"
Cc: c...
Sent: Thu, 28 Feb 2008 12:36:46 -0700
Subject: Re: [c6x] Linker error

> Attached
>
> On Wednesday 27 February 2008 11:48:12 you wrote:
> > Hi jim,
> >
> > Can you share the cmd file to analyze the Section instructions.
> >
> >
> >
> > Regards,
> >
> > Narendra
> >
> >
> >
> > ________________________________
> >
> > From: c... [mailto:c...] On Behalf Of jim
> > Sent: Wednesday, February 27, 2008 1:03 AM
> > To: c...
> > Subject: [c6x] Linker error
> >
> >
> >
> > A program for the 6416 that compiles in code composer 3.1 without error
> > in
> > debug mode fails to link in release mode, giving errors like this:
> >
> > error: memory types ISRAM and ISRAM on page 0 overlap
> >
> > along with lots of warnings of this type:
> >
> > async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> > named '.trace'
> >
> > These values are being set up in the .cdb file for the project, and code
> >
> > composer is writing a cfg.cmd file for the project, and as near as I can
> > tell
> > the linker is trying to use both files and getting confused.
> >
> > How should I handle this?
> >
------- End of Original Message -------

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Yes, I see that now. Here is the contents of the cmd file:

/* Do *not* directly modify this file. It was */
/* generated by the Configuration Tool; any */
/* changes risk being overwritten. */

/* INPUT async_pci.cdb */

/* MODULE PARAMETERS */
GBL_USERINITFXN = _FXN_F_nop;

MEM_SEGZERO = ISRAM;
MEM_MALLOCSEG = ISRAM;

CLK_TIMEFXN = CLK_F_getshtime;
CLK_HOOKFXN = HWI_F_dispatch;

PRD_THOOKFXN = _KNL_tick;

RTDX_DATAMEMSEG = ISRAM;

HST_DSMBUFSEG = ISRAM;

SWI_EHOOKFXN = GBL_NULL;
SWI_IHOOKFXN = GBL_NULL;
SWI_EXECFXN = SWI_F_iexec;
SWI_RUNFXN = SWI_F_run;

TSK_STACKSEG = SDRAM;
TSK_VCREATEFXN = _FXN_F_nop;
TSK_VDELETEFXN = _FXN_F_nop;
TSK_VEXITFXN = _FXN_F_nop;
TSK_SWITCHFXN = _TSK_checkstacks;

IDL_CALIBRFXN = IDL_F_stub;

SYS_ABORTFXN = _UTL_doAbort;
SYS_ERRORFXN = _UTL_doError;
SYS_EXITFXN = _UTL_halt;
SYS_PUTCFXN = _UTL_doPutc;

GIO_CREATEFXN = _SEM_create;
GIO_DELETEFXN = _SEM_delete;
GIO_PENDFXN = _SEM_pend;
GIO_POSTFXN = _SEM_post;

/* OBJECT ALIASES */
_ISRAM = ISRAM;
_SDRAM = SDRAM;
_PCISDRAM = PCISDRAM;
_DATASDRAM = DATASDRAM;
_PRD_clock = PRD_clock;
_PRD0 = PRD0;
_RTA_fromHost = RTA_fromHost;
_RTA_toHost = RTA_toHost;
_HWI_RESET = HWI_RESET;
_HWI_NMI = HWI_NMI;
_HWI_RESERVED0 = HWI_RESERVED0;
_HWI_RESERVED1 = HWI_RESERVED1;
_HWI_INT4 = HWI_INT4;
_HWI_INT5 = HWI_INT5;
_HWI_INT6 = HWI_INT6;
_HWI_INT7 = HWI_INT7;
_HWI_INT8 = HWI_INT8;
_HWI_INT9 = HWI_INT9;
_HWI_INT10 = HWI_INT10;
_HWI_INT11 = HWI_INT11;
_HWI_INT12 = HWI_INT12;
_HWI_INT13 = HWI_INT13;
_HWI_INT14 = HWI_INT14;
_HWI_INT15 = HWI_INT15;
_PRD_swi = PRD_swi;
_KNL_swi = KNL_swi;
_TSK_idle = TSK_idle;
_LNK_dataPump = LNK_dataPump;
_RTA_dispatcher = RTA_dispatcher;
_IDL_cpuLoad = IDL_cpuLoad;
_LOG_system = LOG_system;
_trace = trace;
_IDL_busyObj = IDL_busyObj;

/* MODULE GBL */

SECTIONS {
.vers (COPY): {} /* version information */
}

-priority
-llnknone.a64
-ldrivers.a64 /* device drivers support */
-lsioboth.a64 /* supports both SIO models */
-lbiosi.a64 /* DSP/BIOS support */
-lrtdx64xx.lib /* RTDX support */
-lcsl6416.lib
-lrts6400.lib /* C and C++ run-time library support */

_GBL_CACHE = GBL_CACHE;

/* MODULE MEM */
-stack 0x3000
MEMORY {
ISRAM : origin = 0x0, len = 0x100000
SDRAM : origin = 0x80000000, len = 0xcfffcf
PCISDRAM : origin = 0x80cfffd0, len = 0x2f
DATASDRAM : origin = 0x80d00000, len = 0x300000
}
/* MODULE CLK */
SECTIONS {
.clk: {
_CLK_start = _CLK_start6x;
CLK_F_gethtime = CLK_F_getshtime;
CLK_A_TABBEG = .;
*(.clk)
CLK_A_TABEND = .;
CLK_A_TABLEN = (. - CLK_A_TABBEG) / 1;
} > ISRAM
}
_CLK_PRD = CLK_PRD;
_CLK_COUNTSPMS = CLK_COUNTSPMS;
_CLK_REGS = CLK_REGS;
_CLK_USETIMER = CLK_USETIMER;
_CLK_TIMERNUM = CLK_TIMERNUM;
_CLK_TDDR = CLK_TDDR;

/* MODULE PRD */
SECTIONS {
.prd: {
PRD_A_TABBEG = .;
*(.prd)
PRD_A_TABEND = .;
PRD_A_TABLEN = (. - PRD_A_TABBEG) / 32;
} > ISRAM
}

/* MODULE HWI */
SECTIONS {
.hwi_vec: 0x0 {
HWI_A_VECS = .;
*(.hwi_vec)
}
}

/* MODULE SWI */
SECTIONS {
.swi: {
SWI_A_TABBEG = .;
*(.swi)
SWI_A_TABEND = .;
SWI_A_TABLEN = (. - SWI_A_TABBEG) / 44;
} > ISRAM
}

/* MODULE IDL */
SECTIONS {
.idl: {
IDL_A_TABBEG = .;
*(.idl)
IDL_A_TABEND = .;
IDL_A_TABLEN = (. - IDL_A_TABBEG) / 8;
IDL_A_CALBEG = .;
*(.idlcal)
IDL_A_CALEND = .;
IDL_A_CALLEN = (. - IDL_A_CALBEG) / 8;
} > ISRAM
}

SECTIONS {
.DATASDRAM$heap: {
DATASDRAM$B = .;
_DATASDRAM_base = .;
DATASDRAM$L = 0x1000;
_DATASDRAM_length = 0x1000;
. += 0x1000;
} > DATASDRAM

.sysdata: {} > ISRAM

.trcdata: {} > ISRAM

.gblinit: {} > ISRAM

.mem: {} > ISRAM

.sysinit: {} > ISRAM

.sysregs: {} > ISRAM

.bios: {} > ISRAM

.stack: fill=0xc0ffee {
GBL_stackbeg = .;
*(.stack)
GBL_stackend = GBL_stackbeg + 0x3000 - 1;
_HWI_STKBOTTOM = GBL_stackbeg + 0x3000 - 4 & ~7;
_HWI_STKTOP = GBL_stackbeg;
} > ISRAM

.devtable: {} > ISRAM

.gio: {} > ISRAM

.args: fill=0 {
*(.args)
. += 0x4;
} > ISRAM

.hst: {
HST_A_TABBEG = .;
_HST_A_TABBEG = .;
*(.hst)
HST_A_TABEND = .;
_HST_A_TABEND = .;
HST_A_TABLEN = (. - _HST_A_TABBEG) / 20;
_HST_A_TABLEN = (. - _HST_A_TABBEG) / 20;
} > ISRAM

.dsm: {} > ISRAM

/* RTA_fromHost buffer */
.hst1: align = 0x4 {} > ISRAM

/* RTA_toHost buffer */
.hst0: align = 0x4 {} > ISRAM

.hwi: {} > ISRAM

.tsk: {
*(.tsk)
} > ISRAM

.TSK_idle$stk: {
*(.TSK_idle$stk)
} > ISRAM

.log: {
LOG_A_TABBEG = .;
_LOG_A_TABBEG = .;
*(.log)
LOG_A_TABEND = .;
_LOG_A_TABEND = .;
LOG_A_TABLEN = (. - _LOG_A_TABBEG) / 24;
_LOG_A_TABLEN = (. - _LOG_A_TABBEG) / 24;
} > ISRAM

.printf (COPY): {} > ISRAM

/* LOG_system buffer */
.LOG_system$buf: align = 0x1000 fill = 0xffffffff {} > ISRAM

/* trace buffer */
.trace$buf: align = 0x1000 fill = 0xffffffff {} > ISRAM

.pip: {
PIP_A_TABBEG = .;
_PIP_A_TABBEG = .;
*(.pip)
PIP_A_TABEND = .;
_PIP_A_TABEND = .;
PIP_A_TABLEN = (. - _PIP_A_TABBEG) / 100;
_PIP_A_TABLEN = (. - _PIP_A_TABBEG) / 100;
} > ISRAM

.sts: {
STS_A_TABBEG = .;
_STS_A_TABBEG = .;
*(.sts)
STS_A_TABEND = .;
_STS_A_TABEND = .;
STS_A_TABLEN = (. - _STS_A_TABBEG) / 16;
_STS_A_TABLEN = (. - _STS_A_TABBEG) / 16;
} > ISRAM

.sys: {} > ISRAM

.trace: fill = 0x0 {
_SYS_PUTCBEG = .;
. += 0x200;
_SYS_PUTCEND = . - 1;
} > ISRAM

.udev: {} > ISRAM

.ISRAM$heap: {
ISRAM$B = .;
_ISRAM_base = .;
ISRAM$L = 0x2000;
_ISRAM_length = 0x2000;
. += 0x2000;
} > ISRAM

.SDRAM$heap: {
SDRAM$B = .;
_SDRAM_base = .;
SDRAM$L = 0x8000;
_SDRAM_length = 0x8000;
. += 0x8000;
} > SDRAM

}
On Thursday 28 February 2008 20:07:27 you wrote:
> Jim,
>
> This list does not allow attachments.
> Just cut and paste into a email body
>
> R. Williams
> ---------- Original Message -----------
> From: jim
> To: "Narendra Lakshman"
> Cc: c...
> Sent: Thu, 28 Feb 2008 12:36:46 -0700
> Subject: Re: [c6x] Linker error
>
> > Attached
> >
> > On Wednesday 27 February 2008 11:48:12 you wrote:
> > > Hi jim,
> > >
> > > Can you share the cmd file to analyze the Section instructions.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Narendra
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: c... [mailto:c...] On Behalf Of jim
> > > Sent: Wednesday, February 27, 2008 1:03 AM
> > > To: c...
> > > Subject: [c6x] Linker error
> > >
> > >
> > >
> > > A program for the 6416 that compiles in code composer 3.1 without error
> > > in
> > > debug mode fails to link in release mode, giving errors like this:
> > >
> > > error: memory types ISRAM and ISRAM on page 0 overlap
> > >
> > > along with lots of warnings of this type:
> > >
> > > async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> > > named '.trace'
> > >
> > > These values are being set up in the .cdb file for the project, and
> > > code
> > >
> > > composer is writing a cfg.cmd file for the project, and as near as I
> > > can tell
> > > the linker is trying to use both files and getting confused.
> > >
> > > How should I handle this?
>
> ------- End of Original Message -------

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467

Start a New Thread

I have not done so. The major reason is that I am not clear on what code
composer does differently between debug and release versions, beyond having
lots of tags embedded in the debug code.

I have established, though, that there is some substantial difference; code
compiled in debug mode works well, but when I attempt to generate release
code, and that attempt fails because of the linker problem, I cannot then
back up and re-compile with debug mode because the resulting executable hangs
on the PCI bus. I have to reload the entire project from backup to get a
project in place that has never been compiled in release mode before things
work again.

This is extremely troubling. For the moment, I am just assuming that fixing
the linker problem will also fix the executable problem; if this proves to
not be true, I am in for some good times.

I will investigate the differences in the cmd files between debug and release
code, if that is the first place to look.

On Thursday 28 February 2008 16:15:45 you wrote:
> Jim,
>
> On Tue, Feb 26, 2008 at 1:33 PM, jim wrote:
> > A program for the 6416 that compiles in code composer 3.1 without error
> > in debug mode fails to link in release mode, giving errors like this:
> >
> > error: memory types ISRAM and ISRAM on page 0 overlap
> >
> > along with lots of warnings of this type:
> >
> > async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> > named '.trace'
> >
> > These values are being set up in the .cdb file for the project, and code
> > composer is writing a cfg.cmd file for the project, and as near as I can
> > tell
> > the linker is trying to use both files and getting confused.
> >
> > How should I handle this?
>
> Have you looked at the differences in the in the cfg.cmd files
> generated in debug vs. release mode?? mainly the instances of '.trace'
>
> mikedunn
>

-------------------
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Jim,

When setting up the 'debug' and 'release' modes, they both have to be setup, perferably so that each
configuration (you have setup both configurations, correct?) uses a separate sub directory.
Then, the original source code is not modified.
Part of the setup is to say exactly where the .obj, .lst, etc files for each configuration are located.
I.E. the directory structure should look something like the following:
CCS dir
----lib dir
Project dir
----header dir
----source dir
----debug configuration dir == the 'debug' configuration should point here and have the debug
compile operators
--------.asm dir
--------.obj dir
--------.lst dir
--------.out dir
----release configuration dir == the 'release' configuration should point here and have no debug
compiler operators
--------.asm dir
--------.obj dir
--------.lst dir
--------.out dir

The CCS menu item 'project' has a entry where the different configurations are to be added/selected
The CCS menu item 'project' has a entry where the details for each compile/link, for the currently
selected 'configuration' is setup.

>From you description, it sounds like the configuration items are NOT setup and/or not selected
When such is the case, everything goes into the project directory.
So after performing a compile for 'release', all those '.obj', etc files are in the project
directory. This creates conflicts when stepping between 'debug' and 'release' versions of the project.

R. Williams
---------- Original Message -----------
From: jim
To: c...
Sent: Fri, 29 Feb 2008 09:25:39 -0700
Subject: Re: [c6x] Linker error

> I have not done so. The major reason is that I am not clear on what code
> composer does differently between debug and release versions, beyond having
> lots of tags embedded in the debug code.
>
> I have established, though, that there is some substantial difference; code
> compiled in debug mode works well, but when I attempt to generate release
> code, and that attempt fails because of the linker problem, I cannot then
> back up and re-compile with debug mode because the resulting executable hangs
> on the PCI bus. I have to reload the entire project from backup to get a
> project in place that has never been compiled in release mode before things
> work again.
>
> This is extremely troubling. For the moment, I am just assuming that fixing
> the linker problem will also fix the executable problem; if this proves to
> not be true, I am in for some good times.
>
> I will investigate the differences in the cmd files between debug and release
> code, if that is the first place to look.
>
> On Thursday 28 February 2008 16:15:45 you wrote:
> > Jim,
> >
> > On Tue, Feb 26, 2008 at 1:33 PM, jim wrote:
> > > A program for the 6416 that compiles in code composer 3.1 without error
> > > in debug mode fails to link in release mode, giving errors like this:
> > >
> > > error: memory types ISRAM and ISRAM on page 0 overlap
> > >
> > > along with lots of warnings of this type:
> > >
> > > async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> > > named '.trace'
> > >
> > > These values are being set up in the .cdb file for the project, and code
> > > composer is writing a cfg.cmd file for the project, and as near as I can
> > > tell
> > > the linker is trying to use both files and getting confused.
> > >
> > > How should I handle this?
> >
> > Have you looked at the differences in the in the cfg.cmd files
> > generated in debug vs. release mode?? mainly the instances of '.trace'
> >
> > mikedunn
> > -------------------
------- End of Original Message -------

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

My guess is that .hwi_vec may overwrite other sections in ISRAM;
(the first one placed there seem to be .clk; not sure where .vers
goes).

ISRAM is defined to start at 0:

> MEMORY {
> ISRAM : origin = 0x0, len = 0x100000

.clk, .prd, are placed there; then section .hwi_vec is also allocated
into ISRAM with an absolute load address 0.

> SECTIONS {
> .hwi_vec: 0x0 {

so that interrupt table overwrites part of .clk module. I would suggest to
define ISRAM as (presumably the config tool allows for that)

ISRAM : origin = 0x200, len = 0x100000-0x200

and leave interrupt table as is, as by default ISTP is 0.

Rgds,

Andrew

Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread

Jim,

On Fri, Feb 29, 2008 at 10:24 AM, jim wrote:
> I have not done so. The major reason is that I am not clear on what code
> composer does differently between debug and release versions, beyond having
> lots of tags embedded in the debug code.

Actually the compiler does put more debug info into the '.out' file,
but it is picked off by the loader and is stuffed into the symbol file
on the host that is used by CCS.

Look at the release 'build options' and 'linker options' [I like to
check the large text box at the top for the 'real' options] and
compare them to the debug build options. If you are doing low level
PCI stuff and the build/release optimization is different, you may
have something that should be volatile but isn't. The CCS compiler
has a habit off exposing bugs that 'work just fine in debug' but bite
you when you crank up the optimization level.
BTW, you can make the release build settings identical to the debug
settings and work your way from there. There is nothing magic about
debug and release build except for the default settings.
Also, the c6x compiler is 'a command line compiler' - the settings in
the text box are passed directly to the compiler.
>
> I have established, though, that there is some substantial difference; code
> compiled in debug mode works well, but when I attempt to generate release
> code, and that attempt fails because of the linker problem, I cannot then
> back up and re-compile with debug mode because the resulting executable hangs
> on the PCI bus. I have to reload the entire project from backup to get a
> project in place that has never been compiled in release mode before things
> work again.

That's not good - I've been there and it is pretty slow going.
Hopefully the comparison above will reveal some noticeable differences
in the builds.. Keep in mind that if you made changes to the build
configuration during debug [preprocess definitions etc.], they will
not automatically be automatically transferred to the release build.
>
> This is extremely troubling. For the moment, I am just assuming that fixing
> the linker problem will also fix the executable problem; if this proves to
> not be true, I am in for some good times.
>
> I will investigate the differences in the cmd files between debug and release
> code, if that is the first place to look.

I would suggest pursuing the build options route.

mikedunn
>
> On Thursday 28 February 2008 16:15:45 you wrote:
> > Jim,
> >
> > On Tue, Feb 26, 2008 at 1:33 PM, jim wrote:
> > > A program for the 6416 that compiles in code composer 3.1 without error
> > > in debug mode fails to link in release mode, giving errors like this:
> > >
> > > error: memory types ISRAM and ISRAM on page 0 overlap
> > >
> > > along with lots of warnings of this type:
> > >
> > > async_pcicfg.cmd, line 274: warning: multiple definitions of SECTION
> > > named '.trace'
> > >
> > > These values are being set up in the .cdb file for the project, and code
> > > composer is writing a cfg.cmd file for the project, and as near as I can
> > > tell
> > > the linker is trying to use both files and getting confused.
> > >
> > > How should I handle this?
> >
> > Have you looked at the differences in the in the cfg.cmd files
> > generated in debug vs. release mode?? mainly the instances of '.trace'
> >
> > mikedunn
>
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video Transcoding Solution for Commercial & Consumer End Equipment: www.ti.com/dm6467 Start a New Thread