• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 101 subscribers
  • Views 369 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Possible bug in FFTLIB

Li Zhang2
Prodigy 120 points
Other Parts Discussed in Thread: FFTLIB

Hi, 

I may have discovered a bug that cause cache coherence problem in  fft_sp_2d_r2c and similar functions.

When N1 and N2 are small enough like 16 or 32, after fft_execute returns, the first part of the input/output array may be unchanged (as the same before calling fft_execute()).

I think what causing this is the size of the input is no large enough to flush the in/out array out of cache and ecpy copy the transposed data directly to memory without invalidating the cache.

The problem can be solved by manually invalidating the L2 cache for the input/output buffer after calling fft_execute().

Regards,

Li

  • 0
    Prodigy 120 points

    I'm facing another problem, 

    After invalidating the cache of the IO buffer, a second call to fft_execute will cause an EdmaMgr_wait() wait forever and never returns.

    Any idea on how a cache invalidate operation can cause EdmaMgr_wait() to block forever?

    -----------------------------

    Edit: this is somehow solved by freeing the EDMA channels in ecpyRelease callout fucntion, and I don't know what's really happening. But certainly it's a waste of cycles calling EdmaMgr_Alloc and EdmaMgr_free frequently, especially when the plans can be shared between each fft_execute().

    Li

  • 0 in reply to Li Zhang2
    TI__Mastermind 18320 points

    Li,

    I don't think that anyone knowledgeable about FFTLIB is monitoring the TI-RTOS forum.  So I have once again moved your question over to the device forum in hopes that it will get a faster response there.