Linker error

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 Start a New Thread

>> 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 Start a New Thread

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

Start a New Thread

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

Start a New Thread