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.

C5515 hwafft didn't work! Help!

Hi:

I am working on an AUDIO project which uses hwafft. I read SPRABB6A before implement my codes.

 (1)Here is my codes:

 #define FFT_LENGTH                              FFT_64PTS      

// The Bit-Reverse destination buffer data_br_buf requires an address with

// at least 4+log2(FFT_LENGTH) least significant binary zeros

#pragma DATA_SECTION(data_br_buf, "data_br_buf");

Int32 data_br_buf[FFT_LENGTH];

 

fft_flag   = FFT_FLAG;

scale_flag = NOSCALE_FLAG; 

 

hwafft_br( In_buf, data_br, FFT_LENGTH);  // bit-reverse zero-padded coefficients

 

out_sel = (*Hwafft_Func)(data_br, scratch_fft, fft_flag, scale_flag); // perform FFT

if(out_sel == OUT_SEL_DATA)

{

     //   buff_copy32(data_br, coeffs_fft, FFT_LENGTH);

}

 

(2)Here is my cmd file

-stack    0x0800                /* PRIMARY STACK SIZE    */

-sysstack 0x0800                /* SECONDARY STACK SIZE  */

-heap     0x0800                /* HEAP AREA SIZE        */

 

MEMORY

{

PAGE 0:

VEC(RWX)         : origin = 0000100h length = 000100h  /* on-chip DARAM 1  */

DATA(RWX)     : origin = 0000200h length = 004E00h 

PROG(RX)      : origin = 0005000h length = 010000h  /* PROGRAM size 64K */

 

SARAM_3  (RWX) : origin = 0016000h length = 002000h    /* on-chip SARAM 8K */

SARAM_4  (RWX) : origin = 0018000h length = 002000h    /* on-chip SARAM 8K */

…………………………………………………………

SARAM_30 (RW) : origin = 004C000h length = 002000h       /* on-chip SARAM 8K */

SARAM_31 (RW) : origin = 004E000h length = 002000h       /* on-chip SARAM 8K */

}

SECTIONS

{

  .intvec    : > VEC ALIGN = 256

  .text      : > PROG

  .data      : > DATA

  .cinit     : > PROG

  .switch    : > PROG

  .stack     : > DATA

  .sysstack  : > DATA

  .bss       : > DATA

  .sysmem    : > DATA

  .const     : > PROG

  .cio           : > DATA

  vectors (NOLOAD)

 

// The Bit-Reverse destination buffer data_br_buf requires an address with

// at least 4+log2(FFT_LENGTH) least significant binary zeros

  data_br_buf      : > DATA ALIGN = 1024

  scratch_fft_buf   : > SARAM_4

}

 

// VC5505 (PG1.4) HWAFFT Routines ROM Addresses:

_hwafft_br      = 0x00ff6cd6;

_hwafft_8pts    = 0x00ff6cea;

_hwafft_16pts   = 0x00ff6dd9;

_hwafft_32pts   = 0x00ff6f2f;

_hwafft_64pts   = 0x00ff7238;

_hwafft_128pts  = 0x00ff73cd;

_hwafft_256pts  = 0x00ff75de;

_hwafft_512pts  = 0x00ff77dc;

_hwafft_1024pts = 0x00ff7a56;

 

(3) Here is my problem:

3.1 First of all, Bit reverse function works. But after Hwafft_Func was called, all 64 values in buffer data_br and scratch_fft are all 0.

 

3.2 I set break point in Hwafft_Func and do “Assembly step into” then trace into Hwafft_Func. I trace assembly code step by step until exit the Hwafft_Func. The FFT result is correct.

 

3.3 I do 3.2 again. But I didn’t trace step by step. I let program free run somewhere in Hwafft_Func. Then, The FFT result is incorrect.

 

3.4 I suspect that “interrupt triggerred by 5515 DMA” might be the reason. Then, I modify codes to disable interrupt and … like followings

 

Void DMA_isr();

{

        If ( this is DMA interrupt )

        {

    IRQ_globalDisable();

       IRQ_clearAll();

         IRQ_disableAll();

         IRQ_clear(DMA_EVENT);

         Call audio filter function which includes Hwafft_Func

         IRQ_enable(DMA_EVENT);

         IRQ_globalEnable();

}

}

But the result is incorrect and situation is the same as 3.1, 3.2 and 3.3

 

 

S.O.S!

I need help!

 

Daniel

2011-12-08 16:00

  • C5515's HWAFFT routines only support small memory model! Please refer to the following topic for workarounds in large/huge memory models:

    http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/54489.aspx#193396

    Wish this bug will be fix in later DSP releases.

    Cheers,

  • Hi Cong Van Nguyen:

     Thanks for quick response!

    I found 2 files "hwafft.asm" and "hwafft.h". There are AR2 = AR5 and AR3 = AR4.

    If I replace

    AR2 = AR5

    AR3 = AR4

    by

    XAR2 = XAR5

    XAR3 = XAR4

     

    and recompile.

    Should it work?

     

    If you think it doesn't work, Can you send me hwafft wrapper example source code ( assembly and C file ).

    Thanks again!

     

    Daniel ( mr814313@yahoo.com.tw )

    2011-12-08 17:02


  • Either way will work, Daniel.

  • Hi:

    I modify hwafft.asm.

    ;******************************************************************************
    ; Computes 64-point FFT/IFFT
    ;******************************************************************************
    _hwafft_64pts:

    .......................................................................

                    ; Start first double stage
                    AR0 = AR4   --> XAR0 = XAR4
                    AR1 = AR5   --> XAR1 = XAR5

    .......................................................................

                    ; Start second double stage
                    AR2 = AR5  --> XAR2 = XAR5
                    AR3 = AR4  --> XAR3 = XAR4

    .......................................................................

                    ; Start third double stage
                    AR0 = AR4  ---> XAR0 = XAR4
                    AR1 = AR5 ---> XAR1 = XAR5

    and recompile hwafft.asm.

     

    The result is still incorrect like before

    3.1 First of all, Bit reverse function works. But after Hwafft_Func was called, all 64 values in buffer data_br and scratch_fft are all 0.

    3.2 I set break point in Hwafft_Func and do “Assembly step into” then trace into Hwafft_Func. I trace assembly code step by step until exit the Hwafft_Func. The FFT result is correct.

    3.3 I do 3.2 again. But I didn’t trace step by step. I let program free run somewhere in Hwafft_Func. Then, The FFT result is incorrect.

     

    Help!

     

    I will try _hwafft_wrapper this afternoon.

    Daniel 2011-12-09 11:30

  • Hi:

    I try hwafft_wrapper. The situation is still the same.

    The FFT result is correct when I trace into ROM/RAM code step by step and incorrect when I let program free run.

    Help!

    Daniel 2011-12-09 14:30



  • Hi,

    You can put 2 breakpoints, one before and one right after the call to HWAFFT routine to check whether the buffers are cleared during HWAFFT run time. If no, the bug is in your other codes. If yes, you can use the tracer to see whether the DSP is interrupted during HWAFFT run time.

    Cheers

  • hello,i get a question as you have got. i need you help.How do you solve your problem finally.i wish to your reply .Thanks very much

  • Is it possible to get an update on this problem?

    Many thanks,

    Nathan 

  • I have exactly the same problem. It works tracing step by step but does not work when run all the way. How did you solve it?

    Thanks,

  • I'm running into the exact same issue that Daniel encountered.

    I'm putting a single cycle with a vector magnitude of 1 into a queue:

    queue[0] = 32767;
    queue[1] = 0;
    queue[2] = 23170;
    queue[3] = 23170;
    queue[4] = 0;
    queue[5] = 32767;
    queue[6] = -23170;
    queue[7] = 23170;
    queue[8] = -32767;
    queue[9] = 0;
    queue[10] = -23170;
    queue[11] = -23170;
    queue[12] = 0;
    queue[13] = -32767;
    queue[14] = 23170;
    queue[15] = -23170;

    Then bit reversing it into a "fft_a" buffer (which produces valid data in fft_a)

    hwafft_br(queue,fft_a,8);

    Then calling hwafft_8pts:

    hwafft_8pts(fft_a, fft_b, FFT_FLAG, SCALE_FLAG);

    If I set a breakpoint after the hwafft_8pts call, both fft_a and fft_b buffers are zero. But if I single-step through the hwafft_8pts() function with the emulator, it works fine.

    I'm using two different implementations of hwafft_8pts - first a wrapper function that sets the high 8 bits of the XAR5:0 registers to zero to avoid the known errata in the ROM functions, and secondly running the SPRABB6 "fixed" code out of RAM. Both do the exact same thing - zero result when free-running, perfect result when single-stepping.

    Free-running to certain points in the FFT routine can cause different results - eg, free running to the XAR0 = XAR4 "start 1st double stage" and single stepping from there gives a nonzero, but corrupted, output.

    Help?
  • Figured it out. Make sure the HWAFFT isn't idled in the ICR register.