6711DSK/CCS3/THS1206 - Strange Behaviour

Hi all,

I'll try to avoid this being the typical 'I'm a student, help me,
urgent' type thread...

So, some background to my problem. I'm developing a fairly simple
control program on a 6711 DSK using CCS 3.1. For my application, the
6711 is far from ideal (lacking inbuilt ADC, PWM or GPIO), but I
'inherited' the DSK and unlike the 'F243/XDS510 I tried, it was able
to connect it to the PC so I could have a bash at developing some
code. I'm also using a THS1206EVM, in order to read 4 analogue inputs
(3 from sensors, 1 from a sig-gen). The output of the DSP is PWM at
20kHz on 2 channels, via the I/O Port on the unused lines connected to
TP16-18.

2-channel PWM generation using a single timer made the code somewhat
complicated, but it works. Configuring and reading from the ADC has
proven to be fairly straightforward - for some reason I'm sometimes
finding that the value returned from the ADC contains spurious data in
the upper bits of the value, but AND-ing with 0xFFF reveals that the
data in the lower 12 bits is valid so I'm not too concerned about that
issue.

I am using rts6700.lib, a stack size of 0x400 and the -c (run-time
autoinitialisation) linker option. From inspection of the .map file
and the DSP memory whilst running the code, memory or stack space is
not an issue. For initialisation and interrupt set-up, I am using
c6xdskinit.c, from the R.Chassaing book 'DSP Applications using C and
the TMS320C6x DSK'. This file configures the SDRAM, timers, ADC and
then interrupts. I have encountered no issues with this file itself.

The 'main' section of my program calls the 'initialise' function in
c6xdskinit.c, and then enters an infinite while(1) loop. 2 ISRs
provide all the program functionality - one is driven by the timer
used for PWM generation, the other by the 'data_av' line of the ADC
board. Upon availability of new data, some simple processing is
performed to translate the ADC readings into meaningful values for use
elsewhere in the program. The PWM generation ISR calls the functions
containing the control algorithms (in order to determine the PWM duty
cycle), and then configures the timer and IO port appropriately.

The IST is set up using a modified version of 'vectors_11.asm', to
connect interrupts 10, 11 and 12 with the corresponding C functions.
All variables are explicitly initialised to 0, and I have been careful
to define constants used in FP operations with a decimal point (e.g.
'24.0' rather than '24').

That is the background to my problem, essentially the problem is as
follows: Depending on which sections of the code are commented in or
out, upon building and running the program, with no breakpoints set,
it halts somewhere in c6xdskinit.c, or enters an infinite loop within
that file. The behaviour sometimes changes between builds of the
(same) code (!), typical is something like this:

Program is here upon breaking:
enableSpecificINT(12); //enable interrupt
enableSpecificINT(11); //enable interrupt
enableSpecificINT(10); //enable interrupt

Single-stepping through the code, it will execute these three
statements repeatedly in a loop. Alternatively, it will loop between
the top of the file and the closing '}' or loop between locations in
the disassembly window. Sometimes on loading the program, it will end
up in the disassembly within an 'abort' section, but resetting the CPU
and reloading usually cures this.

The behaviour is inconsistent, I have observed differing 'failure
modes' between resets of the DSK and rebuilds of the code. Usually,
commenting out one of the ISRs will change the behaviour, but only
with the program reduced to calling the initialisation routine and the
while(1) loop will it reliably run at present.

To further compound my frustration, shortly before lab closing today,
the entire code ran without encountering these errors (note: it always
compiles without error/warning and runs perfectly on the 6711 cycle
accurate simulator). Shortly before this, the exact same code was
encountering the run-time errors described above.

Any insights into this behaviour would be much appreciated, as the DSP
issues I have encountered are significantly impeding progress with my
project - it seems perverse that I am spending so much time on what is
essentially a peripheral 'implementation' aspect of the project.

Many thanks,

Niall

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

Hello Niall,

Congratulations on submitting submitting clear background info and
providing an indication that you have actually tried to resolve the
problem on your own.

See comments below.

On Thu, Feb 28, 2008 at 2:35 PM, niall_rockets wrote:

> Hi all,
>
> I'll try to avoid this being the typical 'I'm a student, help me,
> urgent' type thread...
>
> So, some background to my problem. I'm developing a fairly simple
> control program on a 6711 DSK using CCS 3.1. For my application, the
> 6711 is far from ideal (lacking inbuilt ADC, PWM or GPIO), but I
> 'inherited' the DSK and unlike the 'F243/XDS510 I tried, it was able
> to connect it to the PC so I could have a bash at developing some
> code. I'm also using a THS1206EVM, in order to read 4 analogue inputs
> (3 from sensors, 1 from a sig-gen). The output of the DSP is PWM at
> 20kHz on 2 channels, via the I/O Port on the unused lines connected to
> TP16-18.
>
> 2-channel PWM generation using a single timer made the code somewhat
> complicated, but it works. Configuring and reading from the ADC has
> proven to be fairly straightforward - for some reason I'm sometimes
> finding that the value returned from the ADC contains spurious data in
> the upper bits of the value, but AND-ing with 0xFFF reveals that the
> data in the lower 12 bits is valid so I'm not too concerned about that
> issue.
>
> I am using rts6700.lib, a stack size of 0x400 and the -c (run-time
> autoinitialisation) linker option. From inspection of the .map file
> and the DSP memory whilst running the code, memory or stack space is
> not an issue. For initialisation and interrupt set-up, I am using
> c6xdskinit.c, from the R.Chassaing book 'DSP Applications using C and
> the TMS320C6x DSK'. This file configures the SDRAM, timers, ADC and
> then interrupts. I have encountered no issues with this file itself.

Note: I am not familiar with the details of the Chassaing book, but
you should look at the details of the SDRAM initialization code. The
6211/6711 DSKs were built with two different types of SDRAM. The code
that is in the DSK GEL file shows some initialization that is
conditional based on the reading of a revision jumper on the DSK. Make
sure that you are using the correct initialization values.

>
> The 'main' section of my program calls the 'initialise' function in
> c6xdskinit.c, and then enters an infinite while(1) loop. 2 ISRs
> provide all the program functionality - one is driven by the timer
> used for PWM generation, the other by the 'data_av' line of the ADC
> board. Upon availability of new data, some simple processing is
> performed to translate the ADC readings into meaningful values for use
> elsewhere in the program. The PWM generation ISR calls the functions
> containing the control algorithms (in order to determine the PWM duty
> cycle), and then configures the timer and IO port appropriately.
>
> The IST is set up using a modified version of 'vectors_11.asm', to
> connect interrupts 10, 11 and 12 with the corresponding C functions.
> All variables are explicitly initialised to 0, and I have been careful
> to define constants used in FP operations with a decimal point (e.g.
> '24.0' rather than '24').
>
> That is the background to my problem, essentially the problem is as
> follows: Depending on which sections of the code are commented in or
> out, upon building and running the program, with no breakpoints set,
> it halts somewhere in c6xdskinit.c, or enters an infinite loop within
> that file. The behaviour sometimes changes between builds of the
> (same) code (!), typical is something like this:
>
> Program is here upon breaking:
> enableSpecificINT(12); //enable interrupt
> enableSpecificINT(11); //enable interrupt
> enableSpecificINT(10); //enable interrupt
>
> Single-stepping through the code, it will execute these three
> statements repeatedly in a loop. Alternatively, it will loop between
> the top of the file and the closing '}' or loop between locations in
> the disassembly window. Sometimes on loading the program, it will end
> up in the disassembly within an 'abort' section, but resetting the CPU
> and reloading usually cures this.
>
> The behaviour is inconsistent, I have observed differing 'failure
> modes' between resets of the DSK and rebuilds of the code. Usually,
> commenting out one of the ISRs will change the behaviour, but only
> with the program reduced to calling the initialisation routine and the
> while(1) loop will it reliably run at present.

Inconsistent behavior is often a symptom of a memory related problem.
If the problem varies from build to build after making minor changes,
you might have a memory alignment problem or variable initialization
problem.

You did not mention the size of your program or whether it resides in
internal memory or external memory. Any code that resides in internal
memory should be less than 64K. If your code is larger than 64K and
your linker command file [LCF] has a size greater than 0x10000 [a
common error that I have seen], the linker will not give an error when
loading.

If your code runs in external memory, see if you can cut it down
[while keeping some deterministic functionality] to run entirely in
internal memory [IRAM]. Verify that it works [or doesn't] and then
tweak the LCF to run the identical code in external memory {SDRAM].
Relink and try it. Ideally you will end up with results like 'works in
IRAM, fails in SDRAM'.

Hopefully some of this will point you in the right direction. Let us
know what happens.

>
> To further compound my frustration, shortly before lab closing today,
> the entire code ran without encountering these errors (note: it always
> compiles without error/warning and runs perfectly on the 6711 cycle
> accurate simulator). Shortly before this, the exact same code was
> encountering the run-time errors described above.

Have you been using the same power supply for all tests?? If possible,
check the power supply coming into the board [s/b 5v] and the 1.8v and
3.3v outputs. I have seen more than one 6211/6711 DSK problem than
was caused by a bad external power supply.

mikedunn
>
> Any insights into this behaviour would be much appreciated, as the DSP
> issues I have encountered are significantly impeding progress with my
> project - it seems perverse that I am spending so much time on what is
> essentially a peripheral 'implementation' aspect of the project.
>
> Many thanks,
>
> Niall
>
>

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

Michael Dunn wrote:
> Hello Niall,
>
> Inconsistent behavior is often a symptom of a memory related problem.
> If the problem varies from build to build after making minor changes,
> you might have a memory alignment problem or variable initialization
> problem.
>
> You did not mention the size of your program or whether it resides in
> internal memory or external memory. Any code that resides in internal
> memory should be less than 64K. If your code is larger than 64K and
> your linker command file [LCF] has a size greater than 0x10000 [a
> common error that I have seen], the linker will not give an error when
> loading.

I knew I would forget something - as far as I know (I am using a
linker .cmd file I 'inherited' along with the DSK board), the program
resides entirely in IRAM with the exceptions of .sysmem, .far and
.cio. I forget the exact numbers, but I have inspected the memory
contents, and the program content ends at 0x3800 or so, with the stack
beyond that, followed by empty space. The code is only a few hundred
lines of C, total, so I am reasonably sure that memory size or stack
overflow are not the source of my problems.

I need to check with the board to hand, but from a cursory inspection,
the SDRAM configuration seems sensible. I'll dig out the datasheet
tomorrow and check the values for myself though. My project is
primarily power electronics and control based, I didn't anticipate
chasing down bus signals or register values on a DSP board at the
beginning!

> Have you been using the same power supply for all tests?? If possible,
> check the power supply coming into the board [s/b 5v] and the 1.8v and
> 3.3v outputs. I have seen more than one 6211/6711 DSK problem than
> was caused by a bad external power supply.

This is one thing I have not explicitly tested, I shall have a look.

Niall

(P.S. Apologies for any double copies of this message caused by my use
of two email accounts)

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