Leandro,

Header files have to be included whereever some item inside the header file is
needed.

However what I said is that the header files need a 'wrapper' so they would only
be included once.

The correct way to write a header file is:
/**********************
comments
***********************/
#ifndef a_unique_name /* dont include following if a_unique_name is defined */
#define a_unique_name /* define a_unique_name */
.. all the header file contents here
#endif /* close the #ifndef */

regarding 0x80000000 ram addressing
ALL addresses used by a program need to be in the linker command file, including
the 0x80000000 ram addresses

Still, the main problem with the program is that certain items are being
accessed/used that are not initialized.

R. Williams

---------- Original Message -----------
From: "Leandro Della Flora"
To: "Richard Williams"
Cc: m...@gmail.com, c...
Sent: Mon, 8 Sep 2008 10:58:48 -0300
Subject: Re: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1

> Hi Richard,
>
> Thanks for examining the source code. You're right about the linker command
> file. I should have included it before. The content of the file is:
>
> /*C6713dsk.cmd Linker command file*/
> MEMORY
> {
> IVECS: org=0h, len=0x220
> IRAM: org=0x00000220, len=0x0002FDE0 /*internal memory*/
> }
> SECTIONS
> {
> .vecs :> IVECS /*in vector file*/
> .text :> IRAM /*Created by C Compiler*/
> .bss :> IRAM
> .cinit :> IRAM
> .stack :> IRAM
> .sysmem :> IRAM
> .const :> IRAM
> .switch :> IRAM
> .far :> IRAM
> .cio :> IRAM
> .csldata :> IRAM
> }
>
> Regarding the variables rt_ptr, yt_ptr and ut_ptr, they are indeed different
> from rt, yt and ut in the sense that I was planning to make rt, yt and
> ut buffers that store information in the 6713 internal memory, while
> rt_ptr, yt_ptr and ut_ptr are supposed to store data in the external SDRAM.
> According to the DSK manual, the initial address of the 16Mbytes external
> memory is 0x80000000. That's why I declared:
>
> time_ptr = (float *) 0x80000000;
> rt_ptr = (float *) 0x80400000;
> yt_ptr = (float *) 0x80800000;
> ut_ptr = (float *) 0x80C00000;
>
> and initialized them as:
>
> for (ii=0;ii > {
> time_ptr[ii]=0;
> rt_ptr[ii]=0;
> yt_ptr[ii]=0;
> ut_ptr[ii]=0;
> }
>
> where N_ptr was defined as 480,000. The data is then stored during the
> program execution as:
>
> time_ptr[index_ptr] = t*c_Time;
> rt_ptr[index_ptr] = r;
> yt_ptr[index_ptr] = in_adc;
> ut_ptr[index_ptr] = fmax;
> if (index_ptr>=N_ptr-1) {index_ptr=-1;}
> index_ptr++;
>
> where "index_ptr" is declared as "int index_ptr=0;".
>
> I couldn't understand why you said that "most of the 'extern' items should
> be declared 'const' and not 'extern'...". My plan was to declare most
> of the global variables in the control_init.c file and call them in
> other files by using the syntax "extern variable_type variable_name;".
> Please give me some further explanation about that. Concerning the
> "#include", I thought that placing "#include control.h" before "void
> algorithm (){...}" would have no problem. I'm gonna include the header
> files just once and right in the main c source file.
>
> Thanks for your attention,
>
> Leandro.
>
> 2008/9/7 Richard Williams > Leandro,
> >
> > There LOTS wrong with the code.
> >
> > However, the first problem I see is:
> >
> > rt_ptr = (float *) 0x80400000;
> >
> > yt_ptr = (float *) 0x80800000;
> >
> > ut_ptr = (float *) 0x80C00000;
> >
> > If I read your code correctly ( BTW: 1-2 letter variable names is really
> > bad,
> > especially as most of the code is not commented)
> > the above three lines are incorrect as the plan was to get the address of
> > rt[], yt[], and ut[]
> >
> > A good way to get those addresses is:
> > rt_ptr = &rt[0];
> > yt_ptr = &yt[0];
> > ut_ptr = &ut[0];
> >
> >
> > As it is, the code is writing in places of no known value.
> >
> > Perhaps your linker command file is allocating some specific 1024 bytes at
> > each
> > of the above addresses.
> > Also, rt[], has an allocation of 35767 short ints and the code is only
> > handling
> > the first 1024.
> > and why clear all the area to 0x00 when nothing is changing nor using it?
> >
> > Also, most of the 'extern' items should be declared 'const' and not 'extern
> > and
> > the 'const' declarations should be in the control_init.c file.
> >
> >
> > Also, there is '#include' right in the middle of the function
> > 'algorithm()!!!
> > That is definitely not correct.
> >
> > Also, the control.h file needs to have a protective wrapped so it cannot be
> > included twice.
> > I.E.
> > #ifndef control_h
> > #define control_h
> > ....
> > #endif
> >
> > I will get back to you when I have had a chance to examine the code
> > further.
> > I do think the correcting of the setting of the .._ptr values will go a
> > long way
> > toward making the code reliable.
> >
> > Perhaps, on your next reply, you can post the linker .cmd file contents
> >
> > R. Williams
> >
> >
> >
> >
> >
> > ---------- Original Message -----------
> > From: "Leandro Della Flora"
> > To: "Richard Williams"
> > Cc: m...@gmail.com
> > Sent: Tue, 2 Sep 2008 12:34:18 -0300
> > Subject: Re: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1
> >
> > > Hello Mike and Richard,
> > >
> > > Attached are the main .c source and header files that I have been
> > > using. I carefully checked the initialization of the variables,
> > > buffers and pointers but I could not find anything wrong.
> > > "Loop_intr.c" is the main routine which calls functions defined in
> > > "control_init.c" and "control.c". "control.h" contains the constants
> > > that I have defined. Please take a look to see if you can find
> > > something wrong.
> > >
> > > Thanks for your attention,
> > >
> > > Leandro.
> > >
> > > 2008/8/31, Richard Williams :
> > > >
> > > >
> > > > ldellafolora,
> > > >
> > > > The lack of repeatability sounds like an uninitialized area/variable is
> > > > being
> > > > used without being set first.
> > > >
> > > > I would be looking at any variables/buffers/etc to assure they are all
> > > > being
> > > > set/initialized before being used.
> > > > Also, it is my understanding that CCS 3.1 does not support the C6x
> > series
> > > > of
> > > > processors and what is needed is the full version CCS 3.3.
> > > >
> > > > If it is not too long, please post the source (cut/paste, not type it
> > in)
> > > > and we
> > > > could help with the debug.
> > > >
> > > > R. Williams
> > > >
> > > > ---------- Original Message -----------
> > > > From: l...@gmail.com
> > > > To: c...
> > > > Sent: Wed, 27 Aug 2008 17:28:16 -0400
> > > > Subject: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1
> > > >
> > > > > Hi All,
> > > > >
> > > > > I have purchased the book "Digital Signal Processing and Applications
> > > > > with the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a
> > > > > reference to implement digital signal processing routines using the
> > > > > C6713 DSK and CCS 3.1. I have successfully executed the examples
> > > > > provided by Dr. Chassaing in chapters 1 e 2, but with some minor
> > > > > modifications due to warning messages that appeared when I first
> > tried
> > > > > to build the projects. For example: the second chapter starts with a
> > > > > quite simple routine (loop_intr.c) which implements an interrupt-
> > > > > driven (using INT11) loop program to illustrate input and output with
> > > > > the AIC23 codec. Following the steps indicated in the book and
> > > > > building the project, the following message appeared:
> > > > >
> > > > > "warning: Detected a near (.bss section relative) data reference to
> > > > > the symbol _DSK6713_AIC23_codecdatahandle defined in section .far.
> > > > > The eference occurs in C:\CCStudio_v3.1
> > > > > MyProjects\Accel_control\Debug\c6713dskinit.obj, section .text, SPC
> > > > > offset 00000058. Either make the symbol near data by placing it in
> > > > > the .bss section, or make the references to the symbol far. For
> > C/C++
> > > > > code use 'far' or 'near' modifiers on the type definition of the
> > > > > symbol or compile with the --mem_model:data switch."
> > > > >
> > > > > Since this is not an error, I loaded the .out file into the DSP
> > memory
> > > > > and executed the program, but nothing really happened (the system was
> > > > > supposed to acquire a 1 kHz signal generated by an external function
> > > > > generator and send the sample to the left channel DAC).
> > > > >
> > > > > Then, I set the memory model on the compile options to "-
> > > > > -mem_model:data" which was enough to make the program run as
> > > > > expected. However, something "strange" happened next: I have been
> > > > > using this example (and its support files) as a base program to build
> > > > > my own routines (as suggested by Dr. Chassaing). Basically, I
> > > > > introduced my algorithm as a function between the lines that get the
> > > > > data from the codec ADC and send the sample to the DAC (this is the
> > > > > ISR). The control algorithm is quite simple and consists of
> > > > > generating a sine signal to the DAC and storing information in the
> > > > > SDRAM by using pointers. I build the project without errors or
> > warning
> > > > > messages (except one less significant: "warning: last line of file
> > > > > ends without a new line") but, although sometimes it works fine, in
> > > > > many occasions the simple fact of rebuilding and reloading the
> > project
> > > > > without making any modification in the source files causes the system
> > > > > not to work properly (!).
> > > > >
> > > > > The failure is not consistent as I have verified. In many times, when
> > > > > the program doesn't work, I have to rebuild the project using the
> > > > > [WINDOWS-1252?][WINDOWS-1252?]"o3" optimization level to make it
operate as
> > expected
> > (although
> > > > > sometimes this action produces no effect). Then I remove the
> > > > > optimization option, rebuild the project again and it simply works
> > (!)
> > > > > . Later, the introduction of minor and not expressive modifications
> > > > > (such as declaring a new variable) makes the problem to come up
> > again.
> > > > >
> > > > > I read a message posted by Niall in Feb 28 2008
> > ("6711DSK/CCS3/THS1206
> > > > > - Strange Behavior") reporting an inconsistent behavior found on the
> > > > > C6711 DSK with CCS 3.1. I also checked the reply comments posted by
> > > > > Michael but unfortunately there is no evidence that Niall succeeded
> > in
> > > > > resolving the problem. I'm not an experienced DSP algorithm
> > > > > developer and it's possible that I'm committing some kind of
> > > > > simple mistake. I would be very grateful if you could help me in
> > > > > finding the solution to this problem. Based on Niall and Michael
> > > > > comments, I put some extra information below to give a better
> > > > > background about the problem:
> > > > >
> > > > > I'm using all the support files provided by Dr. Chassaing on his
> > > > > book: C6713dskinit.c (to initialize the DSK, the codec, the serial
> > > > > ports and for I/O), C6713dskinit.h (with function prototypes to set
> > > > > input line, input gain and so on), C6713dsk.cmd (sample linker
> > command
> > > > > file), Vectors_intr.asm (a modified version of a vector file
> > included
> > > > > with CCS to handle INT11 interrupt), rts6700.lib, dsk6713bsl.lib,
> > > > > csl6713.lib (run-time, board, and chip support library files).
> > > > >
> > > > > The stack size is 0x400 and I selected the -c (run-time
> > > > > autoinitialisation) linker option. The program resides entirely in
> > the
> > > > > internal memory (RAM L2) and the size of the .out file is 86 kB. The
> > > > > variables stored in the external SDRAM memory are not brought back to
> > > > > the DSP for further computations. The codec sampling frequency is set
> > > > > to 48 kHz and I'm quite sure that the DSP can perform all the
> > > > > calculations required in my routine in less than one sampling period.
> > > > >
> > > > > To generate the sine signal with "sinf()", I'm including
> > > > > fastmath67x.h in my .c source file and adding fastmath67x.lib
> > > > > (declared in the linker options before rts6700.lib as required). The
> > > > > first time I included fastmath67x.lib and loaded the generated .out
> > > > > file, the following message appeared: "Data verification failed at
> > > > > 0x90000000. Please verify target memory and memory map" (!). Then the
> > > > > output file could not be loaded. Since 0x90000000 refers to the flash
> > > > > memory initial address, I removed the line "FLASH: org=0x90000000,
> > > > > len=0x00020000" from the C6713dsk.cmd file, which eliminated the
> > > > > message and allowed CCS to load the program.
> > > > >
> > > > > My apologies for the size of the message. I hope that we find a
> > > > > solution that may also be useful to other people facing similar
> > > > > problems. Many thanks in advance,
> > > > >
> > > > > Leandro.

> Other DSP Related Groups: http://www.dsprelated.com/groups.phpYahoo!
> Groups Links
> Start a New Thread

Hi Richard,

Thanks for examining the source code. You're right about the linker command
file. I should have included it before. The content of the file is:

/*C6713dsk.cmd Linker command file*/
MEMORY
{
IVECS: org=0h, len=0x220
IRAM: org=0x00000220, len=0x0002FDE0 /*internal memory*/
}
SECTIONS
{
.vecs :> IVECS /*in vector file*/
.text :> IRAM /*Created by C Compiler*/
.bss :> IRAM
.cinit :> IRAM
.stack :> IRAM
.sysmem :> IRAM
.const :> IRAM
.switch :> IRAM
.far :> IRAM
.cio :> IRAM
.csldata :> IRAM
}

Regarding the variables rt_ptr, yt_ptr and ut_ptr, they are indeed different
from rt, yt and ut in the sense that I was planning to make rt, yt and
ut buffers that store information in the 6713 internal memory, while rt_ptr,
yt_ptr and ut_ptr are supposed to store data in the external SDRAM.
According to the DSK manual, the initial address of the 16Mbytes external
memory is 0x80000000. That's why I declared:

time_ptr = (float *) 0x80000000;
rt_ptr = (float *) 0x80400000;
yt_ptr = (float *) 0x80800000;
ut_ptr = (float *) 0x80C00000;

and initialized them as:

for (ii=0;ii {
time_ptr[ii]=0;
rt_ptr[ii]=0;
yt_ptr[ii]=0;
ut_ptr[ii]=0;
}

where N_ptr was defined as 480,000. The data is then stored during the
program execution as:

time_ptr[index_ptr] = t*c_Time;
rt_ptr[index_ptr] = r;
yt_ptr[index_ptr] = in_adc;
ut_ptr[index_ptr] = fmax;
if (index_ptr>=N_ptr-1) {index_ptr=-1;}
index_ptr++;

where "index_ptr" is declared as "int index_ptr=0;".

I couldn't understand why you said that "most of the 'extern' items should
be declared 'const' and not 'extern'...". My plan was to declare most of
the global variables in the control_init.c file and call them in other files
by using the syntax "extern variable_type variable_name;". Please give me
some further explanation about that.
Concerning the "#include", I thought that placing "#include control.h"
before "void algorithm (){...}" would have no problem. I'm gonna include the
header files just once and right in the main c source file.

Thanks for your attention,

Leandro.
2008/9/7 Richard Williams

> Leandro,
>
> There LOTS wrong with the code.
>
> However, the first problem I see is:
>
> rt_ptr = (float *) 0x80400000;
>
> yt_ptr = (float *) 0x80800000;
>
> ut_ptr = (float *) 0x80C00000;
>
> If I read your code correctly ( BTW: 1-2 letter variable names is really
> bad,
> especially as most of the code is not commented)
> the above three lines are incorrect as the plan was to get the address of
> rt[], yt[], and ut[]
>
> A good way to get those addresses is:
> rt_ptr = &rt[0];
> yt_ptr = &yt[0];
> ut_ptr = &ut[0];
> As it is, the code is writing in places of no known value.
>
> Perhaps your linker command file is allocating some specific 1024 bytes at
> each
> of the above addresses.
> Also, rt[], has an allocation of 35767 short ints and the code is only
> handling
> the first 1024.
> and why clear all the area to 0x00 when nothing is changing nor using it?
>
> Also, most of the 'extern' items should be declared 'const' and not 'extern
> and
> the 'const' declarations should be in the control_init.c file.
> Also, there is '#include' right in the middle of the function
> 'algorithm()!!!
> That is definitely not correct.
>
> Also, the control.h file needs to have a protective wrapped so it cannot be
> included twice.
> I.E.
> #ifndef control_h
> #define control_h
> ....
> #endif
>
> I will get back to you when I have had a chance to examine the code
> further.
> I do think the correcting of the setting of the .._ptr values will go a
> long way
> toward making the code reliable.
>
> Perhaps, on your next reply, you can post the linker .cmd file contents
>
> R. Williams
>
> ---------- Original Message -----------
> From: "Leandro Della Flora"
> To: "Richard Williams"
> Cc: m...@gmail.com
> Sent: Tue, 2 Sep 2008 12:34:18 -0300
> Subject: Re: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1
>
> > Hello Mike and Richard,
> >
> > Attached are the main .c source and header files that I have been
> > using. I carefully checked the initialization of the variables,
> > buffers and pointers but I could not find anything wrong.
> > "Loop_intr.c" is the main routine which calls functions defined in
> > "control_init.c" and "control.c". "control.h" contains the constants
> > that I have defined. Please take a look to see if you can find
> > something wrong.
> >
> > Thanks for your attention,
> >
> > Leandro.
> >
> > 2008/8/31, Richard Williams :
> > >
> > >
> > > ldellafolora,
> > >
> > > The lack of repeatability sounds like an uninitialized area/variable is
> > > being
> > > used without being set first.
> > >
> > > I would be looking at any variables/buffers/etc to assure they are all
> > > being
> > > set/initialized before being used.
> > > Also, it is my understanding that CCS 3.1 does not support the C6x
> series
> > > of
> > > processors and what is needed is the full version CCS 3.3.
> > >
> > > If it is not too long, please post the source (cut/paste, not type it
> in)
> > > and we
> > > could help with the debug.
> > >
> > > R. Williams
> > >
> > > ---------- Original Message -----------
> > > From: l...@gmail.com
> > > To: c...
> > > Sent: Wed, 27 Aug 2008 17:28:16 -0400
> > > Subject: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1
> > >
> > > > Hi All,
> > > >
> > > > I have purchased the book "Digital Signal Processing and Applications
> > > > with the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a
> > > > reference to implement digital signal processing routines using the
> > > > C6713 DSK and CCS 3.1. I have successfully executed the examples
> > > > provided by Dr. Chassaing in chapters 1 e 2, but with some minor
> > > > modifications due to warning messages that appeared when I first
> tried
> > > > to build the projects. For example: the second chapter starts with a
> > > > quite simple routine (loop_intr.c) which implements an interrupt-
> > > > driven (using INT11) loop program to illustrate input and output with
> > > > the AIC23 codec. Following the steps indicated in the book and
> > > > building the project, the following message appeared:
> > > >
> > > > "warning: Detected a near (.bss section relative) data reference to
> > > > the symbol _DSK6713_AIC23_codecdatahandle defined in section .far.
> > > > The eference occurs in C:\CCStudio_v3.1
> > > > MyProjects\Accel_control\Debug\c6713dskinit.obj, section .text, SPC
> > > > offset 00000058. Either make the symbol near data by placing it in
> > > > the .bss section, or make the references to the symbol far. For
> C/C++
> > > > code use 'far' or 'near' modifiers on the type definition of the
> > > > symbol or compile with the --mem_model:data switch."
> > > >
> > > > Since this is not an error, I loaded the .out file into the DSP
> memory
> > > > and executed the program, but nothing really happened (the system was
> > > > supposed to acquire a 1 kHz signal generated by an external function
> > > > generator and send the sample to the left channel DAC).
> > > >
> > > > Then, I set the memory model on the compile options to "-
> > > > -mem_model:data=far" which was enough to make the program run as
> > > > expected. However, something "strange" happened next: I have been
> > > > using this example (and its support files) as a base program to build
> > > > my own routines (as suggested by Dr. Chassaing). Basically, I
> > > > introduced my algorithm as a function between the lines that get the
> > > > data from the codec ADC and send the sample to the DAC (this is the
> > > > ISR). The control algorithm is quite simple and consists of
> > > > generating a sine signal to the DAC and storing information in the
> > > > SDRAM by using pointers. I build the project without errors or
> warning
> > > > messages (except one less significant: "warning: last line of file
> > > > ends without a new line") but, although sometimes it works fine, in
> > > > many occasions the simple fact of rebuilding and reloading the
> project
> > > > without making any modification in the source files causes the system
> > > > not to work properly (!).
> > > >
> > > > The failure is not consistent as I have verified. In many times, when
> > > > the program doesn't work, I have to rebuild the project using the
> > > > [WINDOWS-1252?]"o3" optimization level to make it operate as
> expected
> (although
> > > > sometimes this action produces no effect). Then I remove the
> > > > optimization option, rebuild the project again and it simply works
> (!)
> > > > . Later, the introduction of minor and not expressive modifications
> > > > (such as declaring a new variable) makes the problem to come up
> again.
> > > >
> > > > I read a message posted by Niall in Feb 28 2008
> ("6711DSK/CCS3/THS1206
> > > > - Strange Behavior") reporting an inconsistent behavior found on the
> > > > C6711 DSK with CCS 3.1. I also checked the reply comments posted by
> > > > Michael but unfortunately there is no evidence that Niall succeeded
> in
> > > > resolving the problem. I'm not an experienced DSP algorithm
> > > > developer and it's possible that I'm committing some kind of
> > > > simple mistake. I would be very grateful if you could help me in
> > > > finding the solution to this problem. Based on Niall and Michael
> > > > comments, I put some extra information below to give a better
> > > > background about the problem:
> > > >
> > > > I'm using all the support files provided by Dr. Chassaing on his
> > > > book: C6713dskinit.c (to initialize the DSK, the codec, the serial
> > > > ports and for I/O), C6713dskinit.h (with function prototypes to set
> > > > input line, input gain and so on), C6713dsk.cmd (sample linker
> command
> > > > file), Vectors_intr.asm (a modified version of a vector file
> included
> > > > with CCS to handle INT11 interrupt), rts6700.lib, dsk6713bsl.lib,
> > > > csl6713.lib (run-time, board, and chip support library files).
> > > >
> > > > The stack size is 0x400 and I selected the -c (run-time
> > > > autoinitialisation) linker option. The program resides entirely in
> the
> > > > internal memory (RAM L2) and the size of the .out file is 86 kB. The
> > > > variables stored in the external SDRAM memory are not brought back to
> > > > the DSP for further computations. The codec sampling frequency is set
> > > > to 48 kHz and I'm quite sure that the DSP can perform all the
> > > > calculations required in my routine in less than one sampling period.
> > > >
> > > > To generate the sine signal with "sinf()", I'm including
> > > > fastmath67x.h in my .c source file and adding fastmath67x.lib
> > > > (declared in the linker options before rts6700.lib as required). The
> > > > first time I included fastmath67x.lib and loaded the generated .out
> > > > file, the following message appeared: "Data verification failed at
> > > > 0x90000000. Please verify target memory and memory map" (!). Then the
> > > > output file could not be loaded. Since 0x90000000 refers to the flash
> > > > memory initial address, I removed the line "FLASH: org=0x90000000,
> > > > len=0x00020000" from the C6713dsk.cmd file, which eliminated the
> > > > message and allowed CCS to load the program.
> > > >
> > > > My apologies for the size of the message. I hope that we find a
> > > > solution that may also be useful to other people facing similar
> > > > problems. Many thanks in advance,
> > > >
> > > > Leandro. Start a New Thread

Richard,

On Sun, Aug 31, 2008 at 11:25 AM, Richard Williams
wrote:
>
> ldellafolora,
>
> The lack of repeatability sounds like an uninitialized area/variable is
> being
> used without being set first.
>
> I would be looking at any variables/buffers/etc to assure they are all being
> set/initialized before being used.
> Also, it is my understanding that CCS 3.1 does not support the C6x series of
> processors and what is needed is the full version CCS 3.3.


Just to flog this dead horse once more, from the CCS 3.1 Release Notes
[the 6713 was added in a later service release]:
1.3 C6000 Family
The following C6000 devices will be supported on this release of
Code Composer Studio:
* Legacy: C6201, C6202, C6211, C6211B, C6414 rev.1, C6415 rev.1,
C6416 rev.1, C6701, C6711C, C6712C, C6202B, C6414 rev.1.1, C6416
rev.1.1, C6411 rev.1.1
* New: C6202B, C6203B, C6204, C6205, C6712C, C6415 rev 1.1
mikedunn
>
> If it is not too long, please post the source (cut/paste, not type it in)
> and we
> could help with the debug.
>
> R. Williams
>
> ---------- Original Message -----------
> From: l...@gmail.com
> To: c...
> Sent: Wed, 27 Aug 2008 17:28:16 -0400
> Subject: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1
>
>> Hi All,
>>
>> I have purchased the book "Digital Signal Processing and Applications
>> with the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a
>> reference to implement digital signal processing routines using the
>> C6713 DSK and CCS 3.1. I have successfully executed the examples
>> provided by Dr. Chassaing in chapters 1 e 2, but with some minor
>> modifications due to warning messages that appeared when I first tried
>> to build the projects. For example: the second chapter starts with a
>> quite simple routine (loop_intr.c) which implements an interrupt-
>> driven (using INT11) loop program to illustrate input and output with
>> the AIC23 codec. Following the steps indicated in the book and
>> building the project, the following message appeared:
>>
>> "warning: Detected a near (.bss section relative) data reference to
>> the symbol _DSK6713_AIC23_codecdatahandle defined in section .far.
>> The eference occurs in C:\CCStudio_v3.1
>> MyProjects\Accel_control\Debug\c6713dskinit.obj, section .text, SPC
>> offset 00000058. Either make the symbol near data by placing it in
>> the .bss section, or make the references to the symbol far. For C/C++
>> code use 'far' or 'near' modifiers on the type definition of the
>> symbol or compile with the --mem_model:data switch."
>>
>> Since this is not an error, I loaded the .out file into the DSP memory
>> and executed the program, but nothing really happened (the system was
>> supposed to acquire a 1 kHz signal generated by an external function
>> generator and send the sample to the left channel DAC).
>>
>> Then, I set the memory model on the compile options to "-
>> -mem_model:data=far" which was enough to make the program run as
>> expected. However, something "strange" happened next: I have been
>> using this example (and its support files) as a base program to build
>> my own routines (as suggested by Dr. Chassaing). Basically, I
>> introduced my algorithm as a function between the lines that get the
>> data from the codec ADC and send the sample to the DAC (this is the
>> ISR). The control algorithm is quite simple and consists of
>> generating a sine signal to the DAC and storing information in the
>> SDRAM by using pointers. I build the project without errors or warning
>> messages (except one less significant: "warning: last line of file
>> ends without a new line") but, although sometimes it works fine, in
>> many occasions the simple fact of rebuilding and reloading the project
>> without making any modification in the source files causes the system
>> not to work properly (!).
>>
>> The failure is not consistent as I have verified. In many times, when
>> the program doesn't work, I have to rebuild the project using the
>> "o3" optimization level to make it operate as expected (although
>> sometimes this action produces no effect). Then I remove the
>> optimization option, rebuild the project again and it simply works (!)
>> . Later, the introduction of minor and not expressive modifications
>> (such as declaring a new variable) makes the problem to come up again.
>>
>> I read a message posted by Niall in Feb 28 2008 ("6711DSK/CCS3/THS1206
>> - Strange Behavior") reporting an inconsistent behavior found on the
>> C6711 DSK with CCS 3.1. I also checked the reply comments posted by
>> Michael but unfortunately there is no evidence that Niall succeeded in
>> resolving the problem. I'm not an experienced DSP algorithm
>> developer and it's possible that I'm committing some kind of
>> simple mistake. I would be very grateful if you could help me in
>> finding the solution to this problem. Based on Niall and Michael
>> comments, I put some extra information below to give a better
>> background about the problem:
>>
>> I'm using all the support files provided by Dr. Chassaing on his
>> book: C6713dskinit.c (to initialize the DSK, the codec, the serial
>> ports and for I/O), C6713dskinit.h (with function prototypes to set
>> input line, input gain and so on), C6713dsk.cmd (sample linker command
>> file), Vectors_intr.asm (a modified version of a vector file included
>> with CCS to handle INT11 interrupt), rts6700.lib, dsk6713bsl.lib,
>> csl6713.lib (run-time, board, and chip support library files).
>>
>> The stack size is 0x400 and I selected the -c (run-time
>> autoinitialisation) linker option. The program resides entirely in the
>> internal memory (RAM L2) and the size of the .out file is 86 kB. The
>> variables stored in the external SDRAM memory are not brought back to
>> the DSP for further computations. The codec sampling frequency is set
>> to 48 kHz and I'm quite sure that the DSP can perform all the
>> calculations required in my routine in less than one sampling period.
>>
>> To generate the sine signal with "sinf()", I'm including
>> fastmath67x.h in my .c source file and adding fastmath67x.lib
>> (declared in the linker options before rts6700.lib as required). The
>> first time I included fastmath67x.lib and loaded the generated .out
>> file, the following message appeared: "Data verification failed at
>> 0x90000000. Please verify target memory and memory map" (!). Then the
>> output file could not be loaded. Since 0x90000000 refers to the flash
>> memory initial address, I removed the line "FLASH: org=0x90000000,
>> len=0x00020000" from the C6713dsk.cmd file, which eliminated the
>> message and allowed CCS to load the program.
>>
>> My apologies for the size of the message. I hope that we find a
>> solution that may also be useful to other people facing similar
>> problems. Many thanks in advance,
>>
>> Leandro.
>>
>>
>>
>>
>>
>>
>>
>>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

Wim-

> I just wanted to clarify one thing that looked strange just now. I'm
> working on my own custom board that's based on a 6713 processor. I've
> been doing all of my development on Code Composer Studio that reports
> it's version as 3.1.23. (and code generation tools 5.90.100.9)

CCS v3.1 should have no problem with C6713 since that device has been out since late 2002. Richard may be referring
to later C64x devices.

I think even C641x devices should be fine in v3.1, but definitely I wouldn't use it for anything to do with C64x+.

-Jeff Start a New Thread

I just wanted to clarify one thing that looked strange just now. I'm
working on my own custom board that's based on a 6713 processor. I've
been doing all of my development on Code Composer Studio that reports
it's version as 3.1.23. (and code generation tools 5.90.100.9)

Richard Williams wrote:
> Also, it is my understanding that CCS 3.1 does not support the C6x series of
> processors and what is needed is the full version CCS 3.3.
>
> Start a New Thread

ldellafolora,

The lack of repeatability sounds like an uninitialized area/variable is being
used without being set first.

I would be looking at any variables/buffers/etc to assure they are all being
set/initialized before being used.
Also, it is my understanding that CCS 3.1 does not support the C6x series of
processors and what is needed is the full version CCS 3.3.

If it is not too long, please post the source (cut/paste, not type it in) and we
could help with the debug.

R. Williams

---------- Original Message -----------
From: l...@gmail.com
To: c...
Sent: Wed, 27 Aug 2008 17:28:16 -0400
Subject: [c6x] Inconsistent failure programming C6713 DSK with CCS 3.1

> Hi All,
>
> I have purchased the book "Digital Signal Processing and Applications
> with the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a
> reference to implement digital signal processing routines using the
> C6713 DSK and CCS 3.1. I have successfully executed the examples
> provided by Dr. Chassaing in chapters 1 e 2, but with some minor
> modifications due to warning messages that appeared when I first tried
> to build the projects. For example: the second chapter starts with a
> quite simple routine (loop_intr.c) which implements an interrupt-
> driven (using INT11) loop program to illustrate input and output with
> the AIC23 codec. Following the steps indicated in the book and
> building the project, the following message appeared:
>
> "warning: Detected a near (.bss section relative) data reference to
> the symbol _DSK6713_AIC23_codecdatahandle defined in section .far.
> The eference occurs in C:\CCStudio_v3.1
> MyProjects\Accel_control\Debug\c6713dskinit.obj, section .text, SPC
> offset 00000058. Either make the symbol near data by placing it in
> the .bss section, or make the references to the symbol far. For C/C++
> code use 'far' or 'near' modifiers on the type definition of the
> symbol or compile with the --mem_model:data switch."
>
> Since this is not an error, I loaded the .out file into the DSP memory
> and executed the program, but nothing really happened (the system was
> supposed to acquire a 1 kHz signal generated by an external function
> generator and send the sample to the left channel DAC).
>
> Then, I set the memory model on the compile options to "-
> -mem_model:data" which was enough to make the program run as
> expected. However, something "strange" happened next: I have been
> using this example (and its support files) as a base program to build
> my own routines (as suggested by Dr. Chassaing). Basically, I
> introduced my algorithm as a function between the lines that get the
> data from the codec ADC and send the sample to the DAC (this is the
> ISR). The control algorithm is quite simple and consists of
> generating a sine signal to the DAC and storing information in the
> SDRAM by using pointers. I build the project without errors or warning
> messages (except one less significant: "warning: last line of file
> ends without a new line") but, although sometimes it works fine, in
> many occasions the simple fact of rebuilding and reloading the project
> without making any modification in the source files causes the system
> not to work properly (!).
>
> The failure is not consistent as I have verified. In many times, when
> the program doesn’t work, I have to rebuild the project using the
> "–o3" optimization level to make it operate as expected (although
> sometimes this action produces no effect). Then I remove the
> optimization option, rebuild the project again and it simply works (!)
> . Later, the introduction of minor and not expressive modifications
> (such as declaring a new variable) makes the problem to come up again.
>
> I read a message posted by Niall in Feb 28 2008 ("6711DSK/CCS3/THS1206
> - Strange Behavior") reporting an inconsistent behavior found on the
> C6711 DSK with CCS 3.1. I also checked the reply comments posted by
> Michael but unfortunately there is no evidence that Niall succeeded in
> resolving the problem. I’m not an experienced DSP algorithm
> developer and it’s possible that I’m committing some kind of
> simple mistake. I would be very grateful if you could help me in
> finding the solution to this problem. Based on Niall and Michael
> comments, I put some extra information below to give a better
> background about the problem:
>
> I’m using all the support files provided by Dr. Chassaing on his
> book: C6713dskinit.c (to initialize the DSK, the codec, the serial
> ports and for I/O), C6713dskinit.h (with function prototypes to set
> input line, input gain and so on), C6713dsk.cmd (sample linker command
> file), Vectors_intr.asm (a modified version of a vector file included
> with CCS to handle INT11 interrupt), rts6700.lib, dsk6713bsl.lib,
> csl6713.lib (run-time, board, and chip support library files).
>
> The stack size is 0x400 and I selected the -c (run-time
> autoinitialisation) linker option. The program resides entirely in the
> internal memory (RAM L2) and the size of the .out file is 86 kB. The
> variables stored in the external SDRAM memory are not brought back to
> the DSP for further computations. The codec sampling frequency is set
> to 48 kHz and I’m quite sure that the DSP can perform all the
> calculations required in my routine in less than one sampling period.
>
> To generate the sine signal with "sinf()", I’m including
> fastmath67x.h in my .c source file and adding fastmath67x.lib
> (declared in the linker options before rts6700.lib as required). The
> first time I included fastmath67x.lib and loaded the generated .out
> file, the following message appeared: "Data verification failed at
> 0x90000000. Please verify target memory and memory map" (!). Then the
> output file could not be loaded. Since 0x90000000 refers to the flash
> memory initial address, I removed the line "FLASH: org=0x90000000,
> len=0x00020000" from the C6713dsk.cmd file, which eliminated the
> message and allowed CCS to load the program.
>
> My apologies for the size of the message. I hope that we find a
> solution that may also be useful to other people facing similar
> problems. Many thanks in advance,
>
> Leandro.
>
> Start a New Thread

Leandro,

Thanks for the thorough message. You do not have to apologize for the
length when it contains useful background information. Your message
also shows that you have taken some initiative to attempt to resolve
your problem - that is always appreciated.

Please see my comments below.

mikedunn

On Wed, Aug 27, 2008 at 4:28 PM, wrote:
> Hi All,
>
> I have purchased the book "Digital Signal Processing and Applications with the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a reference to implement digital signal processing routines using the C6713 DSK and CCS 3.1. I have successfully executed the examples provided by Dr. Chassaing in chapters 1 e 2, but with some minor modifications due to warning messages that appeared when I first tried to build the projects. For example: the second chapter starts with a quite simple routine (loop_intr.c) which implements an interrupt-driven (using INT11) loop program to illustrate input and output with the AIC23 codec. Following the steps indicated in the book and building the project, the following message appeared:
>
> "warning: Detected a near (.bss section relative) data reference to the symbol _DSK6713_AIC23_codecdatahandle defined in section .far. The eference occurs in C:\CCStudio_v3.1 MyProjects\Accel_control\Debug\c6713dskinit.obj, section .text, SPC offset 00000058. Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far. For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch."
>
> Since this is not an error, I loaded the .out file into the DSP memory and executed the program, but nothing really happened (the system was supposed to acquire a 1 kHz signal generated by an external function generator and send the sample to the left channel DAC).


Note: The reason that it is not an error [I think] is that sometimes
there is some 'clever hardware' or a use of function pointers that
cause the program flow to change in a way that is not obvious to the
compiler.

>
> Then, I set the memory model on the compile options to "--mem_model:data=far" which was enough to make the program run as expected. However, something "strange" happened next: I have been using this example (and its support files) as a base program to build my own routines (as suggested by Dr. Chassaing). Basically, I introduced my algorithm as a function between the lines that get the data from the codec ADC and send the sample to the DAC (this is the ISR). The control algorithm is quite simple and consists of generating a sine signal to the DAC and storing information in the SDRAM by using pointers. I build the project without errors or warning messages (except one less significant: "warning: last line of file ends without a new line") but, although sometimes it works fine, in many occasions the simple fact of rebuilding and reloading the project without making any modification in the source files causes the system not to work properly (!).
>
> The failure is not consistent as I have verified. In many times, when the program doesn't work, I have to rebuild the project using the "o3" optimization level to make it operate as expected (although sometimes this action produces no effect). Then I remove the optimization option, rebuild the project again and it simply works (!). Later, the introduction of minor and not expressive modifications (such as declaring a new variable) makes the problem to come up again.


I think that what you are seeing is the classic case of an
uninitialized variable somewhere in your code [there is also a
possibility that you are using more stack than you have allocated].
When you change the optimization level it changes the 'memory
footprint' of your code [puts some different 1s and 0s in different
places]. I predict that if you always start your program in the same
environment [like mem=0s] that you will always get the same results.

The problem likely lies in your 'added code' or its interface to the
original code.
1. Since this is easy, initialize your stack with a fixed pattern like
0xBABEFACE. This is easy to identify and if the DSP tries to execute
it, it will halt. After you run your program, verify that there are
still locations containing 0xBABEFACE in the stack. If not, you will
need to increase the stack size.

2. Carefully review your code for the use of uninitialized or
incorrectly initialized variables and pointers. Most of us are not
very good at finding our own errors because we see the code in terms
of what we expect it to do as opposed to what it does. I find that
one of the easiest ways to locate mistakes is to explain the code to a
knowledgeable person - one of you will locate the snafu.

3. If none of the above resolves your problem, set some breakpoints in
your code and step through it for correct behavior.
Note: If you get past 1 or 2 buffers, you may have to reload or
restart your program due to some missed interrupts.

>
> I read a message posted by Niall in Feb 28 2008 ("6711DSK/CCS3/THS1206 - Strange Behavior") reporting an inconsistent behavior found on the C6711 DSK with CCS 3.1. I also checked the reply comments posted by Michael but unfortunately there is no evidence that Niall succeeded in resolving the problem. I'm not an experienced DSP algorithm developer and it's possible that I'm committing some kind of simple mistake. I would be very grateful if you could help me in finding the solution to this problem. Based on Niall and Michael comments, I put some extra information below to give a better background about the problem:
>
> I'm using all the support files provided by Dr. Chassaing on his book: C6713dskinit.c (to initialize the DSK, the codec, the serial ports and for I/O), C6713dskinit.h (with function prototypes to set input line, input gain and so on), C6713dsk.cmd (sample linker command file), Vectors_intr.asm (a modified version of a vector file included with CCS to handle INT11 interrupt), rts6700.lib, dsk6713bsl.lib, csl6713.lib (run-time, board, and chip support library files).
>
> The stack size is 0x400 and I selected the -c (run-time autoinitialisation) linker option. The program resides entirely in the internal memory (RAM L2) and the size of the .out file is 86 kB. The variables stored in the external SDRAM memory are not brought back to the DSP for further computations. The codec sampling frequency is set to 48 kHz and I'm quite sure that the DSP can perform all the calculations required in my routine in less than one sampling period.
>
> To generate the sine signal with "sinf()", I'm including fastmath67x.h in my .c source file and adding fastmath67x.lib (declared in the linker options before rts6700.lib as required). The first time I included fastmath67x.lib and loaded the generated .out file, the following message appeared: "Data verification failed at 0x90000000. Please verify target memory and memory map" (!). Then the output file could not be loaded. Since 0x90000000 refers to the flash memory initial address, I removed the line "FLASH: org=0x90000000, len=0x00020000" from the C6713dsk.cmd file, which eliminated the message and allowed CCS to load the program.
>
> My apologies for the size of the message. I hope that we find a solution that may also be useful to other people facing similar problems. Many thanks in advance,
>
> Leandro.
>
>
>
>
>
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

Hi All,

I have purchased the book "Digital Signal Processing and Applications with the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a reference to implement digital signal processing routines using the C6713 DSK and CCS 3.1. I have successfully executed the examples provided by Dr. Chassaing in chapters 1 e 2, but with some minor modifications due to warning messages that appeared when I first tried to build the projects. For example: the second chapter starts with a quite simple routine (loop_intr.c) which implements an interrupt-driven (using INT11) loop program to illustrate input and output with the AIC23 codec. Following the steps indicated in the book and building the project, the following message appeared:

"warning: Detected a near (.bss section relative) data reference to the symbol _DSK6713_AIC23_codecdatahandle defined in section .far. The eference occurs in C:\CCStudio_v3.1 MyProjects\Accel_control\Debug\c6713dskinit.obj, section .text, SPC offset 00000058. Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far. For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch."

Since this is not an error, I loaded the .out file into the DSP memory and executed the program, but nothing really happened (the system was supposed to acquire a 1 kHz signal generated by an external function generator and send the sample to the left channel DAC).

Then, I set the memory model on the compile options to "--mem_model:data" which was enough to make the program run as expected. However, something "strange" happened next: I have been using this example (and its support files) as a base program to build my own routines (as suggested by Dr. Chassaing). Basically, I introduced my algorithm as a function between the lines that get the data from the codec ADC and send the sample to the DAC (this is the ISR). The control algorithm is quite simple and consists of generating a sine signal to the DAC and storing information in the SDRAM by using pointers. I build the project without errors or warning messages (except one less significant: "warning: last line of file ends without a new line") but, although sometimes it works fine, in many occasions the simple fact of rebuilding and reloading the project without making any modification in the source files causes the system not to work properly (!).

The failure is not consistent as I have verified. In many times, when the program doesn’t work, I have to rebuild the project using the "–o3" optimization level to make it operate as expected (although sometimes this action produces no effect). Then I remove the optimization option, rebuild the project again and it simply works (!). Later, the introduction of minor and not expressive modifications (such as declaring a new variable) makes the problem to come up again.

I read a message posted by Niall in Feb 28 2008 ("6711DSK/CCS3/THS1206 - Strange Behavior") reporting an inconsistent behavior found on the C6711 DSK with CCS 3.1. I also checked the reply comments posted by Michael but unfortunately there is no evidence that Niall succeeded in resolving the problem. I’m not an experienced DSP algorithm developer and it’s possible that I’m committing some kind of simple mistake. I would be very grateful if you could help me in finding the solution to this problem. Based on Niall and Michael comments, I put some extra information below to give a better background about the problem:

I’m using all the support files provided by Dr. Chassaing on his book: C6713dskinit.c (to initialize the DSK, the codec, the serial ports and for I/O), C6713dskinit.h (with function prototypes to set input line, input gain and so on), C6713dsk.cmd (sample linker command file), Vectors_intr.asm (a modified version of a vector file included with CCS to handle INT11 interrupt), rts6700.lib, dsk6713bsl.lib, csl6713.lib (run-time, board, and chip support library files).

The stack size is 0x400 and I selected the -c (run-time autoinitialisation) linker option. The program resides entirely in the internal memory (RAM L2) and the size of the .out file is 86 kB. The variables stored in the external SDRAM memory are not brought back to the DSP for further computations. The codec sampling frequency is set to 48 kHz and I’m quite sure that the DSP can perform all the calculations required in my routine in less than one sampling period.

To generate the sine signal with "sinf()", I’m including fastmath67x.h in my .c source file and adding fastmath67x.lib (declared in the linker options before rts6700.lib as required). The first time I included fastmath67x.lib and loaded the generated .out file, the following message appeared: "Data verification failed at 0x90000000. Please verify target memory and memory map" (!). Then the output file could not be loaded. Since 0x90000000 refers to the flash memory initial address, I removed the line "FLASH: org=0x90000000, len=0x00020000" from the C6713dsk.cmd file, which eliminated the message and allowed CCS to load the program.

My apologies for the size of the message. I hope that we find a solution that may also be useful to other people facing similar problems. Many thanks in advance,

Leandro. Start a New Thread