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.

.data:twiddle entry in .cmd file makes program hang

Hi everybody,

I try to use rfft in my C5509A project.

To verify things, I have just plugged in the same test vector as has been used in the test program of the rfft example in. But the results were absolutely not the same as the provided result test vector. I then realized, that the results are completely random for the same test vector(!) so I guessed there might be a bug in the rfft or the way I use rfft. After checking out this forum and the excellent thread by Brian, I tried to align the twiddle data + my input buffer correctly. (However, the randomness of results maybe due to the problem stated in errata when using unpack, not due to bad fft data alignment.)

But after doing the alignment, things got even worse: now the program completely hangs! Even when I remove the alignment from the .data:twiddle statement the program hangs (i.e. there's only the section entry without particular alignment).

This is a full running firmware that needs some improvement on the quality of results therefore I'd need to use fft. But like this it's just useless...:(
I think there may be a memory issue. Since I use pretty big buffers, I am short on memory, I use CSL mainly for USB, I use timers, DMA, EMIF etc. So it's kind of difficult to experiment around without running into placement-fails-linker problems due to the huge size of the buffers and of the program...

Is there anything someone of you could suggest I could tryout or where the problem is?
I'd appreciate that a lot.

Andreas

btw. here's my cmd file:

MEMORY
{
    PAGE 0:

        /* reserved memory */
        MMR            : origin = 0000000h, length = 00000c0h    /* 192 bytes memory mapped registers */
        SPRAM        : origin = 00000c0h, length = 0000040h    /*  64 bytes ??                 */

        /* interrupt table */
        VECS        : origin = 0000100h, length = 0000100h    /* 256 bytes interrupt table    */

        /* ~ 64kBytes internal dual-access RAM */
        DARAM        : origin = 0000200h, length = 000FE00h    /* ~ 64kBytes internal dual-access RAM */

        /*  192kBytes internal single-access RAM */

/*        SARAM        : origin = 0010000h, length = 001EC00h  */
/*        SARAM_EXT    : origin = 002EC00h, length = 000B400h  */
/*        DMA_RAM     : origin = 003A000h, length = 0006000h  */

        SARAM_00to07 : origin = 010000h, length = 010000h  /* 8 blocks, 64 k */
        SARAM_08to15 : origin = 020000h, length = 010000h  /* 8 blocks, 64 k */
/*        SARAM_16to23 : origin = 030000h, length = 010000h  */   /* 8 blocks, 64 k */    
        SARAM_16to23 : origin = 030000h, length = 00EC00h  /* 8 blocks, 64 k  - 5kbytes */
        BOOTLOADER   : origin = 03EC00h, length = 001400h  /* last 5kbytes of the SARAM */



        /* ~ 16MBytes external address space */
        SDRAM        : origin = 0050000h, length = 03B0000h    /* ~ 4MBytes SDRAM              */
        FLASH        : origin = 0400000h, length = 03E0000h    /* ~ 4MBytes FLASH              */
        CPLD        : origin = 07E0000h, length = 0020000h    /* 128kBytes CPLD address space */
        CE2            : origin = 0800000h, length = 0400000h    /*   4MBytes DC address space 0 */
        CE3            : origin = 0c00000h, length = 03F8000h    /*   4MBytes DC address space 1 */

        /* 32kBytes ROM */
        PDROM        : origin = 0ff8000h, length = 0007f00h    /* ~ 32kBytes ROM                */

}       

 
SECTIONS
{
        /* interrupt table */
        .vector        : {}                > VECS                PAGE 0          

        /* default C55x compiler sections */
        .stack        : {}                > DARAM                PAGE 0
        .sysstack    : {}                > DARAM             PAGE 0
        .sysmem        : {}                > DARAM             PAGE 0
        .data        : {}                > DARAM             PAGE 0
        .text        : {}                > SARAM_00to07        PAGE 0
        .const        : {}                > SARAM_08to15         PAGE 0
        
        /* default C55x compiler sections */
        .cinit        : {}                > SARAM_00to07         PAGE 0
        .bss        : {}                > SARAM_08to15        PAGE 0
        
        /* chip select library */
        .csldata     : {}                > SARAM_08to15         PAGE 0
        .usb_api     : {}                > SARAM_00to07         PAGE 0
        .usb_drvr    : {}                > SARAM_00to07         PAGE 0
        api_vect    : {}                 > SARAM_16to23         PAGE 0
        api_lut        : align 2 {}        > SARAM_16to23         PAGE 0
        
        /* general purpose single-access memory for firmware */
        saram_00to07 : {}            >    SARAM_00to07     PAGE 0
        saram_08to15 : {}            >    SARAM_08to15     PAGE 0
        saram_16to23 : {}            >    SARAM_16to23     PAGE 0

        /* general purpose double-access memory for firmware */
        daram  : {}                > DARAM        PAGE 0
        
        /* FFT-specific sections  */
        .fftcode  : {} > SARAM_00to07 PAGE 0          
        .data:twiddle  : {} > SARAM_08to15 PAGE 0
        fftinput : align 2 {} > DARAM        PAGE 0
}

I use the Boot.s55 provided by TI for environment initialization.
Finally, stack size = 0x1000 and heap size = 0x0000.

  • Oh. How stupid of me. When reading my own post I realized that I didn't put .data and .data:twiddle in the same 64k page.
    Writing things correctly, the problem disappeared.

    rfft results are same between dsplib compilation with -v5509A and -v5510:2 [the default]. however the results have about 1-bit average difference when compared to the test vector provided with the examples. but I guess this is fine since I suppose the test vector data is taken from MATLAB or similar...

    So I think things are OK now for the moment  and I am happy to continue the development.:)

    Best regards,

    Andreas