This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

FFT interrupt problems on C6713



I am trying to implement a real time FFT/iFFT code on the C6713 DSK. I am a EE student still learning C programming, so there are some aspects of programming I am not too familiar with. I am am using the dsk_app program as a template and adding the FFT function inside the 'processBuffer()' loop. I think something is causing me to get bad data in the FFT loop. When I view the memory location of the "x" buffer, I see 1.#QNAN for every value. From reading I think that it is a problem with the FFT function being interrupted during processing, but I don't know if I do global int disable on each side of the FFT functions if this will fix the problem. From my understanding, the dsplib FFT functions already do this in the assembly code. I have attached the part of the code I am referring to.

void processBuffer(void)
{
    Uint32 pingPong;

    /* Get contents of mailbox posted by edmaHwi */
    pingPong =  SWI_getmbox();

    /* Copy data from transmit to receive, could process audio here */
    if (pingPong == PING) {


for( i = 0 ; i < FFTSIZE/RADIX ; i++ )		//Create twiddle array
	{
		W[i].re = cos(DELTA*i); 		//real component of W
		W[i].im = sin(DELTA*i); 		//neg imag component
	}

	digitrev_index(iTwid, FFTSIZE/RADIX, RADIX); 	//obtain index for bitrev()W
	bitrev(W, iTwid, FFTSIZE/RADIX); 		//bit reverse W
	
	for(i=0; i<FFTSIZE/2; i++)			//initialize Xmag array
        {
	Xmag[i] = 0;
        }
	 				    	       
           	for( i = 0 ; i < FFTSIZE/2 ; i++ ) 
           	{
           		//window = -.5*cos(2.*PI*(i/FFTSIZE))+.5;
			    x[i].re = gBufferRcvPing[i];//*window;     //external input
           		x[i].im = 0.0;          //zero imaginary part
            			    
        	}

					             //init output magnitude
        	cfftr2_dit(x, W, FFTSIZE) ;		//TI floating-pt complex FFT
  		for( i = 0; i < FFTSIZE/2; i++)			//preserve non-br fft array 
  		{
			intermediate[i].re = x[i].re;		//for ifft routine
			intermediate[i].im = x[i].im;
 		}
		digitrev_index(iData, FFTSIZE, RADIX);		//produces index for bitrev() X
		bitrev(x, iData, FFTSIZE);			//freq scrambled->bit-reverse x
		
		icfftr2_dif(intermediate,W,FFTSIZE);
	    for (i =0; i<FFTSIZE/2; i++)
		 {
		 gBufferRcvPing[i] = intermediate[i].re;
		 }
		 
		for(i = 0; i < FFTSIZE/2; i++)
		
  		Xmag[i] = sqrt(x[i].re*x[i].re+x[i].im*x[i].im)/32;
/* Copy receive PING buffer to transmit PING buffer */
        copyData(gBufferRcvPing, gBufferXmtPing, BUFFSIZE);

  • JPY,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

    If your problem is with the FFT function being interrupted during processing, then doing a global int disable just before calling the FFT function (and enable just after) will eliminate any interrupts from occurring during the FFT function.

    Regards,
    RandyP

  • RandyP,

    Thank you for your reply. I have looked at all the TI resources I can find, and some other resources too, and can't seem to find a situation similar to mine. I did the global int disable on each side of my processing functions and the problem still seems to exist. I notice that the complex interleave works fine and data shows in memory. It is after the FFT function is called when the "1.#QNAN" value shows, so I know that the fft function is causing the QNAN value. I have reviewed the DSPLIB literature once more, and it just explains the QNAN, but not what causes it. Is there something that triggers the QNAN value to be returned from the cfftr2 function? 

  • JPY,

    As you can tell, "from reading I think that..." is not a practical debug method. You had to try something to disprove something that you may not have believed to really be the problem anyway.

    More than 99% of the time, the right answer is that there is something wrong with your input data or values. There should be some usage examples that come with the library. If not for the specific function you are calling, then at least for another similar fft function. Start with something simple until you are able to get it to work, then build up from there until you have your desired function working.

    The data is supposed to be stored a certain way for the complex numbers. The length of the buffers needs to be specified in the right units, per the DSPLIB documentation, and then you may have constraints on the data, again from the documentation.

    You will be best served by assuming the function will work correctly with the right data input. The easiest way to solve it, in my opinion, is to start with some simple data like a sine wave and use way oversized buffers but specify correct (smaller) sizes for the function call.

    Hope this helps a little,
    RandyP