and here is the answer, per TI. I did this and it worked:
Jim,
Thank you for contacting Texas Instruments Technical Support. The Service
Request #1-599754042 has been assigned to your inquiry.
CCS 3.1 worked differently with linker command files than CCS 3.3 does. Most
CCS 3.1 projects included two separate linker command files in the project,
but only one can be automatically linked in. The custom, user-defined command
file would include the BIOS-generated command file with the –l option
(e.g., -l bioscfg.cmd). CCS 3.3 no longer requires this workaround as it can
include both in the project; however, because the custom command file is also
linking in the bios command file it is basically being included twice, thus
the multiple definition errors.
The easiest way to fix this is to go into your custom command file and remove
the –l option which links in the bios-generated command file. If you
continue
to receive errors it may be easier for me to debug the issue directly by
sending me a copy of the project (if possible).
Regards,
Tim Harron
DSP Applications
Texas Instruments
Semiconductor Technical Support
On Thursday 06 March 2008 08:43:35 you wrote: > Well, unfortunately, that change didn't cause
any change in the error
> messages. Guess it is time to call TI.
>
> On Saturday 01 March 2008 07:57:36 you wrote:
> > 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
>
Check Out Industry's First Single-Chip, Multi-Format, Real-Time HD Video
Transcoding Solution for Commercial & Consumer End Equipment:
www.ti.com/dm6467
Reply by jim●March 6, 20082008-03-06
Well, unfortunately, that change didn't cause any change in the error
messages. Guess it is time to call TI.
On Saturday 01 March 2008 07:57:36 you wrote: > 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
Reply by Andrew Nesterov●March 5, 20082008-03-05
>> 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
Fortunately this is not the case. CCS creates Debug/Release subdirs by
itself,
without an user intervention. There're also never ever conflicts between
debug
and release .outs of the same project.
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
Reply by jim●March 4, 20082008-03-04
You are correct; none of this is set up and I have taken the CC defaults for
pretty much everything.
I am learning CC over the course of this project, using documentation from TI
as I find it and as I identify a need for information that I don't have.
It
is pretty clear that there is some conflict between debug and release
versions; reorganizing the project so that they are separated is something I
will certainly try.
This newsgroup has been of inestimable help in a couple of instances, and if
you help me sort out this particular issue, then once again you will have
been of considerable help. I will investigate the organizational changes and
will report back.
On Friday 29 February 2008 20:21:15 you wrote: > 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
Reply by Michael Dunn●March 1, 20082008-03-01
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
Reply by Andrew Nesterov●March 1, 20082008-03-01
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
Reply by Richard Williams●March 1, 20082008-03-01
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
Reply by jim●February 29, 20082008-02-29
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
Reply by jim●February 29, 20082008-02-29
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. */
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 */
}
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
Reply by Richard Williams●February 29, 20082008-02-29
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