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.

NaN output with FFT using DSPLIB

Other Parts Discussed in Thread: OMAP3530

Hello,

I am currently working on a DSP based FFT solution using a DM816x EVM. I am using the ARM (runs Linux) to send samples to the DSP (SYS/BIOS) using IPC and syslink and this link works perfectly. Then the FFT operation is performed on the DSP using dsplib v3.1.1 provided by Texas Instruments. I am calling the function DSPF_sp_ifftSPxSP and I have checked the restriction that apply to it (memory allignment, size...). However, the output is all NaN floats.

The DSP part works perfectly baremetal, without the IPC part. So, any idea how IPC could interfer with dsplib?

Thanks in advance,

  • Hi Xabier,

    Thanks for your post.

    To start with, there is a demonstration app. (DSPF_sp_ifftSPxSP_d.c) for DSPF_sp_ifftSPxSP kernel in the DSP library package which is a complex inverse FFT with mixed radix driver code tests the kernel and reports the benchmark results of CPU cycles (Success/Failure). If you run this project first, you will be able to validate the usage of this kernel in your scenario which is in the installation path as below:

    ~\dsplib_c674x_3_1_0_0\packages\ti\dsplib\src\DSPF_sp_ifftSPxSP\c674\DSPF_sp_ifftSPxSP_674LE_LE_COFF

    Next, please refer the below wiki for the C674x DSPLIB Known issues for DSPF_sp_ifftSPxSP kernel:

    http://processors.wiki.ti.com/index.php/C674x_DSPLIB_Known_Issues#DSPF_sp_fftSPxSP_and_DSPF_sp_ifftSPxSP_Functions_Overwrite_the_Input_Buffer

    Also, please refer the below E2E thread for the similar usecase as yours which would give you an idea on the impact of DSPLINK intervention with the dsplib but it is for OMAP3530 EVM and

    http://e2e.ti.com/support/embedded/bios/f/355/p/150484/559542.aspx#559542

    As per your usecase, there could be many possibilities but please make sure that the DSP and ARM are exchanging same input and output data through DSPLINK. You can exchange checksum data on both ARM & DSP to ensure the same.

    1. Probem could be with the usage of dsplib function for IFFT

    2. It could be the data mismatch between ARM and DSP through IPC

    3. Issue could be with the array/buffer size between ARM and DSP through DSPLINK

    4. might be a scaling range issue

    Please also refer the below wiki to get an idea on how to debug the dsp side of a dsplink application,

    http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_DSPLink_application_on_OMAP_using_CCS#Modify_the_DSPLink_message_example

    I also recommend you to refer the DSPLINK API documentation which would be in the dsplink source installation path as below:

    ~/dsplink_1_xx_xx_xx/dsplink/doc/source_documentation/html/index.html

    Thanks & regards,

    Sivaraj K

    ---------------------------------------------------------------------------------
    Please click the
    Verify Answer button on this post if it answers your question.
    ---------------------------------------------------------------------------------

     

     

  • Hi,

    Thank you for your reply, it ended up being very useful. I have finally spotted the cause of my missbehaviour. I have double checked that the IFFT function worked correctly for non-IPC transmitted values (i.e. values stored in the DSP). So the missusage of the dsplib was discarded.

    Then, I decided to check if the ARM was sending the correct samples through IPC and here is where I spotted the problem. At first glance, the transmitted and received array looked the same, however after having implemented a checksum and seeing that they didn't match I decided to further explore the values. I found that some isolated values (around 10 values out of 4096 transmitted floats) were incorrect. As I am using shared memory to transmit the data, the error comes from the early file parsing stage.

    I don't know if this is the right place to solve these issues, but well, there it goes. I am reading the values from a text file as follows:

    Float* ReadFrame(){
        char line[30];
        FILE *fr;
        Float framePtr[4096];
        fr = fopen ("frame.txt", "rt"); 
        Int index=0;
        while(fgets(line, 15, fr) != NULL)
           {
             sscanf (line, "%f", &framePtr[index]);
             index++;
           }
           fclose(fr);  /* close the file prior to exiting the routine */
           return framePtr;

    }

    Thanks again

  • Hi Xabier,

    Glad to hear that your issue got spotted. Thanks for the update.

    Always, checksum implementation would reveal any data mismatch between two core processor especially when you communicate through IPC mechanism. I suggest, scaling should also be used in an optimum range.

    If you think, the above reply answers your post, please do the below action:

    ---------------------------------------------------------------------------------
    Please click the
    Verify Answer button on this post if it answers your question.
    ---------------------------------------------------------------------------------

    Thanks & regards,

    Sivaraj K

     

     

  • Hi Xabier,

    If your FFT implementation on the DSP is a cache based implementation, make sure you invalidate the cache for the input buffers on the DSP and also write back invalidate the output buffers before you send back the results to ARM.

    Regards,

    Rahul

  • Hello,

    OK. Issue definitely solved, finally I solved the issue by deleting the ReadFrame function and reading the text file directly from where it was needed. It looked like there were some issues with the pointer returned by the function. Now it all works smooth.

    Thank you for everything.