Forums

speed problem on tms320f2812

Started by lukasz_masta March 6, 2006
Hi!
I have wrote a simple program on eZdsp with tms320f2812 frocesor using
Code Composer Studio 2.0, witch in a loop sets and clears one of the
optput lines. I have set the system clock frequency to 150Mhz and by
using #pragma CODE_SECTION.. placed that loop int the h0 memory section
of processor. But when I'am running my program the output signal
frequency is only 10Mhz. My loop has olny 4 simple instructions, and h0
has no wait states so the output signal frequency should be above
37Mhz. Has anybody got an idea why it is like that?
Thanks for all answers.

I think the witch has cast a spell on your code.

Put a scope on the XCLKOUT line and see what you are reading for the
clock out signal.  I believe the default value, unless you have changed
the registers, is for the clockout to be 1/4 the SYSCLK (PLL multiplied
clock in).  Early on in my development, I found that things appeared to
be intermitantly running slow if I was executing out of flash on
powerup.  In my case, it turned out that the reset wasn't occuring
properly.

While this may also be obvious, be sure to check the pull up / down pin
that determines whether or not the PLL is engaged.  You will need to do
more than verify that the jumper is in place as you may have a bad
connection.

The XCLKOUT is OK, but I will try your other advices.
Thanks

lukasz_masta wrote:
> Hi! > I have wrote a simple program on eZdsp with tms320f2812 frocesor using > Code Composer Studio 2.0, witch in a loop sets and clears one of the > optput lines. I have set the system clock frequency to 150Mhz and by > using #pragma CODE_SECTION.. placed that loop int the h0 memory section > of processor. But when I'am running my program the output signal > frequency is only 10Mhz. My loop has olny 4 simple instructions, and h0 > has no wait states so the output signal frequency should be above > 37Mhz. Has anybody got an idea why it is like that? > Thanks for all answers. >
I imagine you're probably just doing an AND, an OR, and a branch. Since the AND and OR are of the same memory location you're going to incur some pipeline stalls (28x has protected pipeline so asm programmer doesn't have to think about this). Similarly there will be some overhead for the branch as well. That's probably why it's so "slow". Note that the I/O buffers on this part are only spec'd up to 20 MHz so you don't want to try and put out signals faster than that. If you're just trying to get a sanity check that instructions are executing at 150 MHz you should try inserting several NOPS between instructions. That way you will know exactly how many instructions are being executed (i.e. the CPU will not put in pipeline stalls do to your back-to-back accesses of the same location). Brad
Hi!
I found the solution. I wrote my program in assembler and it's OK. The
compiler put some unnessesery code in my loop.

Certainly not the first, nor will it be the last time someone gets bit
by the compiler.