Re: [NDO NEWT] [SPAM] (Re: 6711DSK/CCS3/THS1206 - Strange Behaviour)

Niall,

On Thu, Feb 28, 2008 at 4:47 PM, Niall Oswald
wrote:
> 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.

Forget about SDRAM and put everything in IRAM [at least for now] -
that way it doesn't matter about the EMIF settings EXCEPT for the CE
space that has your I/O. FYI - You can look at the LCF by just
opening the file in your project that ends in '.cmd'.

You could be inadvertently putting an array on the stack. Initialize
the stack space to an easily recognizable pattern like '0xdeadbeef' or
'0xbabeface'. After your program runs, the locations that are not over
written will tell you 'how much you did not use'.
Note: For debug purposes you can always over allocate your stack by 'a
lot' and use the results above [with some margin] to correctly size
it.

A common error to to overrun an array or buffer and step on some code
[or other data].

When you find the problem, it will probably be 'something simple'.

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

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

Right, an update. I went into the lab this morning, logged onto the
PC, fired up the DSK, powered up the other hardware and started up
CCS. I loaded the code I had been working on at the end of the
previous day, built it and loaded the program.

Would you believe it, it worked first time. Nothing had changed!
Between 10am and 4pm I didn't have to power-cycle the DSK once, a
couple of CPU Resets required but otherwise no strange behaviour. I
was able to work on debugging my program for once!

I now have a range of interesting issues to address, not least the
propensity of the THS1206 to go on strike when faced with noise (I'm
going to have to write some code to reset it when the readings have
been constant for a few PWM cycles). I need to reduce the amount of
noise overall and re-instate averaging of the ADC readings as they
don't play nicely with my PD control loop. I spent ages trying to
figure out why what I expected to be a constant output was jumping
around at half the ADC sample rate - turned out to be due to noise
amplified by the Kd term...

I'm just hoping the 6711 will be able to keep up with PWM generation
at 20kHz and sampling at 200kHz.

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