DSPRelated.com
Forums

RFFT from dsplib not working...

Started by pet_dsp October 5, 2004


Hello everybody,
I am wondering if any experts here could help solve
my problems with using rfft (routine from TI's dsplib) on a 5402 DSP.
Here is my scenario,

Codec --> DMA (block size = 256 samples) --> CPU (do 256-pt FFT) -->
see results by plotting a graph (in CCS).

The codec and DMA are setup correctly, the codec
input is a 1Khz sine wave, and the codec samples @ 40KHz. I can see
the input data in the dma destination buffer and it looks good. I
copy the DMA destination buffer to an array x which is defined as,

#define NX 256
#pragma DATA_SECTION (x,".inputdata")
DATA x[NX];

The data copied into 'x' is not corrupted in any
way, i checked that. Now i am trying to do a 256-pt real FFT using
the rfft routine from TI's dsplib library. This is the way i invoke
rfft,

cbrev(x,x,NX/2);
rfft(x,NX,1);

After this when i plot 'x', i don't see a single
peak in the frequency domain, rather the o/p looks like the FFT of
some broadband audio. Can somebody please explain what i am doing
wrong?

Thanks in advance,
Deepak.



Deepak-

You are trying to debug too much at one time. Try passing this to rfft():

-x[0] = 1
-x[2, 4, ...NX-2] = 0
-x[1, 3, ...NX-1] = 0

That should produce all 1's in the magnitude domain (remember your basic impulse
response, haha). If you don't get a correct result, then you know cbrev() or
rfft()
is the problem. You can try the same thing without calling cbrev() and
eliminate it
as well. Otherwise your audio/dma is the problem (which I suspect).

-Jeff pet_dsp wrote:
>
> Hello everybody,
> I am wondering if any experts here could help solve
> my problems with using rfft (routine from TI's dsplib) on a 5402 DSP.
> Here is my scenario,
>
> Codec --> DMA (block size = 256 samples) --> CPU (do 256-pt FFT) -->
> see results by plotting a graph (in CCS).
>
> The codec and DMA are setup correctly, the codec
> input is a 1Khz sine wave, and the codec samples @ 40KHz. I can see
> the input data in the dma destination buffer and it looks good. I
> copy the DMA destination buffer to an array x which is defined as,
>
> #define NX 256
> #pragma DATA_SECTION (x,".inputdata")
> DATA x[NX];
>
> The data copied into 'x' is not corrupted in any
> way, i checked that. Now i am trying to do a 256-pt real FFT using
> the rfft routine from TI's dsplib library. This is the way i invoke
> rfft,
>
> cbrev(x,x,NX/2);
> rfft(x,NX,1);
>
> After this when i plot 'x', i don't see a single
> peak in the frequency domain, rather the o/p looks like the FFT of
> some broadband audio. Can somebody please explain what i am doing
> wrong?
>
> Thanks in advance,
> Deepak.






Jeff,
Just figured out the problem. The problem is with the memory
alignment of the array 'x' that is input to the cbrev funtion.
Document spru518c (p-33) says, "input data (x) must be aligned
at 2*nx boundary. The log(nx) + 1 LSBits of address x must be zero."
I did not align 'x' on a 512-word boundary (log(256)+1 LSB's must
have been 0). Once i fixed this in the linker definition file, i got
the fft results as expected for a sine wave input.
Anyways, thank you for a useful debugging tip.

Best regards,
Deepak. --- In , Jeff Brower <jbrower@s...> wrote:
> Deepak-
>
> You are trying to debug too much at one time. Try passing this to
rfft():
>
> -x[0] = 1
> -x[2, 4, ...NX-2] = 0
> -x[1, 3, ...NX-1] = 0
>
> That should produce all 1's in the magnitude domain (remember your
basic impulse
> response, haha). If you don't get a correct result, then you know
cbrev() or rfft()
> is the problem. You can try the same thing without calling cbrev()
and eliminate it
> as well. Otherwise your audio/dma is the problem (which I
suspect).
>
> -Jeff > pet_dsp wrote:
> >
> > Hello everybody,
> > I am wondering if any experts here could help
solve
> > my problems with using rfft (routine from TI's dsplib) on a 5402
DSP.
> > Here is my scenario,
> >
> > Codec --> DMA (block size = 256 samples) --> CPU (do 256-pt FFT) -
->
> > see results by plotting a graph (in CCS).
> >
> > The codec and DMA are setup correctly, the codec
> > input is a 1Khz sine wave, and the codec samples @ 40KHz. I can
see
> > the input data in the dma destination buffer and it looks good. I
> > copy the DMA destination buffer to an array x which is defined as,
> >
> > #define NX 256
> > #pragma DATA_SECTION (x,".inputdata")
> > DATA x[NX];
> >
> > The data copied into 'x' is not corrupted in any
> > way, i checked that. Now i am trying to do a 256-pt real FFT using
> > the rfft routine from TI's dsplib library. This is the way i
invoke
> > rfft,
> >
> > cbrev(x,x,NX/2);
> > rfft(x,NX,1);
> >
> > After this when i plot 'x', i don't see a
single
> > peak in the frequency domain, rather the o/p looks like the FFT of
> > some broadband audio. Can somebody please explain what i am doing
> > wrong?
> >
> > Thanks in advance,
> > Deepak.



Deepak-

> Just figured out the problem. The problem is with the memory
> alignment of the array 'x' that is input to the cbrev funtion.
> Document spru518c (p-33) says, "input data (x) must be aligned
> at 2*nx boundary. The log(nx) + 1 LSBits of address x must be zero."
> I did not align 'x' on a 512-word boundary (log(256)+1 LSB's must
> have been 0). Once i fixed this in the linker definition file, i got
> the fft results as expected for a sine wave input.
> Anyways, thank you for a useful debugging tip.

Ok then you're on your way. The 2*nx alignment is because the .asm language
instructions inside rfft() uses a chip-level "circular address mode". Some DSP
devices even offer "bit-reversed" addressing mode.

-Jeff

> --- In , Jeff Brower <jbrower@s...> wrote:
> > Deepak-
> >
> > You are trying to debug too much at one time. Try passing this to
> rfft():
> >
> > -x[0] = 1
> > -x[2, 4, ...NX-2] = 0
> > -x[1, 3, ...NX-1] = 0
> >
> > That should produce all 1's in the magnitude domain (remember your
> basic impulse
> > response, haha). If you don't get a correct result, then you know
> cbrev() or rfft()
> > is the problem. You can try the same thing without calling cbrev()
> and eliminate it
> > as well. Otherwise your audio/dma is the problem (which I
> suspect).
> >
> > -Jeff
> >
> >
> > pet_dsp wrote:
> > >
> > > Hello everybody,
> > > I am wondering if any experts here could help
> solve
> > > my problems with using rfft (routine from TI's dsplib) on a 5402
> DSP.
> > > Here is my scenario,
> > >
> > > Codec --> DMA (block size = 256 samples) --> CPU (do 256-pt FFT) -
> ->
> > > see results by plotting a graph (in CCS).
> > >
> > > The codec and DMA are setup correctly, the codec
> > > input is a 1Khz sine wave, and the codec samples @ 40KHz. I can
> see
> > > the input data in the dma destination buffer and it looks good. I
> > > copy the DMA destination buffer to an array x which is defined as,
> > >
> > > #define NX 256
> > > #pragma DATA_SECTION (x,".inputdata")
> > > DATA x[NX];
> > >
> > > The data copied into 'x' is not corrupted in any
> > > way, i checked that. Now i am trying to do a 256-pt real FFT using
> > > the rfft routine from TI's dsplib library. This is the way i
> invoke
> > > rfft,
> > >
> > > cbrev(x,x,NX/2);
> > > rfft(x,NX,1);
> > >
> > > After this when i plot 'x', i don't see a
> single
> > > peak in the frequency domain, rather the o/p looks like the FFT of
> > > some broadband audio. Can somebody please explain what i am doing
> > > wrong?
> > >
> > > Thanks in advance,
> > > Deepak.
>
> _____________________________________
> 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:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://www.yahoogroups.com/group/c54x
>
> Other Groups: http://www.dsprelated.com
>
> Yahoo! Groups Links >
>