AD535 | BIOS | Booting | Bootloader | C621 | C6211 | C6415 | C671 | C6711 | C6711DSK | C6713 | CCS | Chassaing | COFF | DAT | DM64 | DM642 | DMA | DSK671 | DSK6711 | EDM | EDMA | EMIF | Emulator | EVM | EVM620 | FFT | FIR | GPIO | Halting | HPI | HWI | IDK | JTAG | LDB | LDH | LDW | Linker | LMS | LOG_printf | Matlab | McBSP | MEM_alloc | MIPS | PCI | PCM3003 | Pipeline | Profiling | QDM | Reset | ROM | RTDX | Sampling | SDRAM | Stack | TEB | THS1206 | TMS320C621 | TMS320C6416 | TMS320C6711 | TMS320C6713 | UART | Vector Table | XBUS | XDS560

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.

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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,  <l...@gmail.com> wrote:
> Hi All,
>
> I have purchased the book "Digital Signal Processing and Applications wit=
h the C6713 and C6416 DSK (by Rulph Chassaing, 2005)" as a reference to imp=
lement digital signal processing routines using the C6713 DSK and CCS 3.1. =
I have successfully executed the examples provided by Dr. Chassaing in chap=
ters 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 a=
n interrupt-driven (using INT11) loop program to illustrate input and outpu=
t with the AIC23 codec. Following the steps indicated in the book and build=
ing the project, the following message appeared:
>
> "warning: Detected a near (.bss section relative) data reference to the s=
ymbol _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 an=
d executed the program, but nothing really happened (the system was suppose=
d to acquire a 1 kHz signal generated by an external function generator and=
 send the sample to the left channel DAC).

<mld>
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=
=3Dfar" which was enough to make the program run as expected. However, some=
thing "strange" happened next: I have been using this example (and its supp=
ort 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  ge=
nerating a sine signal to the DAC and storing information in the SDRAM by u=
sing pointers. I build the project without errors or warning messages (exce=
pt one less significant: "warning: last line of file ends without a new lin=
e") but, although sometimes it works fine, in many occasions the simple fac=
t of rebuilding and reloading the project without making any modification i=
n 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 "=96o3" opti=
mization level to make it operate as expected (although sometimes this acti=
on 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.

<mld>
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=3D0s] 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 DS=
K with CCS 3.1. I also checked the reply comments posted by Michael but unf=
ortunately there is no evidence that Niall succeeded in resolving the probl=
em. 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 M=
ichael comments, I put some extra information below to give a better backgr=
ound about the problem:
>
> I'm using all the support files provided by Dr. Chassaing on his book: C6=
713dskinit.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 interr=
upt), rts6700.lib, dsk6713bsl.lib, csl6713.lib (run-time, board, and chip s=
upport library files).
>
> The stack size is 0x400 and I selected the -c (run-time autoinitialisatio=
n) 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 ex=
ternal SDRAM memory are not brought back to the DSP for further computation=
s. The codec sampling frequency is set to 48 kHz and I'm quite sure that th=
e 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 optio=
ns before rts6700.lib as required). The first time I included fastmath67x.l=
ib and loaded the generated .out file, the following message appeared: "Dat=
a verification failed at 0x90000000. Please verify target memory and memory=
 map" (!). Then the output file could not be loaded. Since 0x90000000 refer=
s to the flash memory initial address, I removed the line "FLASH: org=3D0x9=
0000000, len=3D0x00020000" 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 thank=
s in advance,
>
> Leandro.
>
> ------------------------------------
>
> OMAP35x EVM jump-starts low-power apps
> ------------------------------------
> The modular and extensible OMAP35x Evaluation Module (EVM) enables develo=
pers to start building applications based on the OMAP35x architecture: http=
://www.DSPRelated.com/omap35x
>
> NEW!  You can now post a message or access and search the archives of thi=
s group on DSPRelated.com:
> http://www.dsprelated.com/groups/c6x/1.php
>
> _____________________________________
> Note: If you do a simple "reply" with your email client, only the author =
of this message will receive your answer.  You need to do a "reply all" if =
you want your answer to be distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> Archives:  http://www.dsprelated.com/groups/c6x/1.php
>
> To Post:  Send an email to c...@yahoogroups.com
>
> Other DSP Related Groups: http://www.dsprelated.com/groups.phpYahoo! Grou=
ps Links

--=20
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables develope=
rs to start building applications based on the OMAP35x architecture: http:/=
/www.DSPRelated.com/omap35x

NEW!  You can now post a message or access and search the archives of this =
group on DSPRelated.com:
http://www.dsprelated.com/groups/c6x/1.php

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of=
 this message will receive your answer.  You need to do a "reply all" if yo=
u want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

Archives:  http://www.dsprelated.com/groups/c6x/1.php

To Post:  Send an email to c...@yahoogroups.com

Other DSP Related Groups: http://www.dsprelated.com/groups.phpYahoo! Groups=
 Links

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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...@yahoogroups.com
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.
> 
> ------------------------------------
> 
> OMAP35x EVM jump-starts low-power apps
> ------------------------------------
> The modular and extensible OMAP35x Evaluation Module (EVM) enables 
> developers to start building applications based on the OMAP35x 
> architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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.
>
>   

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

Richard,

On Sun, Aug 31, 2008 at 11:25 AM, Richard Williams
<r...@lewiscounty.com> 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 be=
ing
> 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.

<mld>
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...@yahoogroups.com
> 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=3Dfar" 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
>> "=96o3" 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=3D0x90000000,
>> len=3D0x00020000" 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.
>>
>> ------------------------------------
>>
>> OMAP35x EVM jump-starts low-power apps
>> ------------------------------------
>> The modular and extensible OMAP35x Evaluation Module (EVM) enables
>> developers to start building applications based on the OMAP35x
>> architecture:http://www.DSPRelated.com/omap35x
>>
>> NEW! You can now post a message or access and search the archives of
>> this group on DSPRelated.com: http://www.dsprelated.com/groups/c6x/1.php
>>
>> _____________________________________
>> Note: If you do a simple "reply" with your email client, only the
>> author of this message will receive your answer. You need to do a
>> "reply all" if you want your answer to be distributed to the entire grou=
p.
>>
>> _____________________________________
>> About this discussion group:
>>
>> Archives: http://www.dsprelated.com/groups/c6x/1.php
>>
>> To Post: Send an email to c...@yahoogroups.com
>>
>> Other DSP Related Groups: http://www.dsprelated.com/groups.phpYahoo!
>> Groups Links
>>=20

--=20
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables develope=
rs to start building applications based on the OMAP35x architecture: http:/=
/www.DSPRelated.com/omap35x

NEW!  You can now post a message or access and search the archives of this =
group on DSPRelated.com:
http://www.dsprelated.com/groups/c6x/1.php

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of=
 this message will receive your answer.  You need to do a "reply all" if yo=
u want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

Archives:  http://www.dsprelated.com/groups/c6x/1.php

To Post:  Send an email to c...@yahoogroups.com

Other DSP Related Groups: http://www.dsprelated.com/groups.phpYahoo! Groups=
 Links

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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=3D0h,    len=3D0x220
  IRAM:  org=3D0x00000220, len=3D0x0002FDE0 /*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 differen=
t
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 =3D (float *) 0x80000000;
rt_ptr =3D (float *) 0x80400000;
yt_ptr =3D (float *) 0x80800000;
ut_ptr =3D (float *) 0x80C00000;

and initialized them as:

 for (ii=3D0;ii<N_ptr;ii++)
   {
   time_ptr[ii]=3D0;
   rt_ptr[ii]=3D0;
   yt_ptr[ii]=3D0;
   ut_ptr[ii]=3D0;
   }

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

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

where "index_ptr" is declared as "int index_ptr=3D0;".

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 file=
s
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 th=
e
header files just once and right in the main c source file.

Thanks for your attention,

Leandro.
2008/9/7 Richard Williams <r...@lewiscounty.com>

> Leandro,
>
> There LOTS wrong with the code.
>
> However, the first problem I see is:
>
>        rt_ptr =3D (float *) 0x80400000;
>
>        yt_ptr =3D (float *) 0x80800000;
>
>        ut_ptr =3D (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 =3D &rt[0];
> yt_ptr =3D &yt[0];
> ut_ptr =3D &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 a=
t
> 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 'exte=
rn
> 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" <l...@gmail.com>
> To: "Richard Williams" <r...@lewiscounty.com>
> 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 <r...@lewiscounty.com>:
> > >
> > >
> > > 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 al=
l
> > > 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...@yahoogroups.com
> > > 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 Applicatio=
ns
> > > > 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 wi=
th
> > > > 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 w=
as
> > > > supposed to acquire a 1 kHz signal generated by an external functio=
n
> > > > generator and send the sample to the left channel DAC).
> > > >
> > > > Then, I set the memory model on the compile options to "-
> > > > -mem_model:data=3Dfar" 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 bui=
ld
> > > > my own routines (as suggested by Dr. Chassaing). Basically, I
> > > > introduced my algorithm as a function between the lines that get th=
e
> > > > 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 syst=
em
> > > > not to work properly (!).
> > > >
> > > > The failure is not consistent as I have verified. In many times, wh=
en
> > > > the program doesn't work, I have to rebuild the project using the
> > > > [WINDOWS-1252?]"=96o3" 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 th=
e
> > > > 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.  T=
he
> > > > variables stored in the external SDRAM memory are not brought back =
to
> > > > the DSP for further computations. The codec sampling frequency is s=
et
> > > > 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 perio=
d.
> > > >
> > > > 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). Th=
e
> > > > 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 t=
he
> > > > output file could not be loaded. Since 0x90000000 refers to the fla=
sh
> > > > memory initial address, I removed the line "FLASH: org=3D0x90000000=
,
> > > > len=3D0x00020000" 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.
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables develope=
rs to start building applications based on the OMAP35x architecture: http:/=
/www.DSPRelated.com/omap35x

NEW!  You can now post a message or access and search the archives of this =
group on DSPRelated.com:
http://www.dsprelated.com/groups/c6x/1.php

_____________________________________
Note: If you do a simple "reply" with your email client, only the author of=
 this message will receive your answer.  You need to do a "reply all" if yo=
u want your answer to be distributed to the entire group.

_____________________________________
About this discussion group:

Archives:  http://www.dsprelated.com/groups/c6x/1.php

To Post:  Send an email to c...@yahoogroups.com

Other DSP Related Groups: http://www.dsprelated.com/groups.phpYahoo! Groups=
 Links

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )

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" <l...@gmail.com>
To: "Richard Williams" <r...@lewiscounty.com>
Cc: m...@gmail.com, c...@yahoogroups.com
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<N_ptr;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 <r...@lewiscounty.com> > 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" <l...@gmail.com>
> > To: "Richard Williams" <r...@lewiscounty.com>
> > 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 <r...@lewiscounty.com>:
> > > >
> > > >
> > > > 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...@yahoogroups.com
> > > > 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?][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
> 
------------------------------------

OMAP35x EVM jump-starts low-power apps
------------------------------------
The modular and extensible OMAP35x Evaluation Module (EVM) enables developers to start building
applications based on the OMAP35x architecture:http://www.DSPRelated.com/omap35x

(You need to be a member of c6x -- send a blank email to c6x-subscribe@yahoogroups.com )