• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 323 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EDMA Ticking on OMAPL138

Matan Aloni
Prodigy 175 points

Other Parts Discussed in Thread: OMAPL138

Hello,
We are working on TI's OMAPL138/C6748 to create a basic input to output audio application, using EDMA and double buffering.
We implemented stereo audio channel sorting with double buffers using the EDMA. 
The audio is sampled by the McASP, copied and sorted using the EDMA to ping-pong buffers, and when a buffer is full a hardware interrupt by the EDMA to the CPU is triggered. The HWI then posts a SWI to do the processing on the buffers. 
We managed to get a clean input to output loop-back when the input buffer is copied directly to the output buffer. 
However, when adding more work in the processing stage, the output is corrupted and it sounds like we have a constant "ticking" on top of the input signal.
The extra work doesn't even have to manipulate the data itself - we can add a dummy loop that does nothing, and the output will still get corrupted. 
We have established that this is not an issue of overlapping processing periods between the two buffers by setting a GPIO pin high whenever processing occurs and then monitoring this pin. It looks like processing time is much shorter than the time it takes to fill another buffer. 
BTW, Analysing the frequency of these tick sounds we find that it is at the exact frequency as that of filling a buffer - i.e. a tick is generated once a buffer.
Printing the input and output buffers we see that one sample (usually the first) is "corrupted" - its' value isn't as expected (using an input sinusoidal waveform).
Do you have any ideas for debugging the issue?
Thanks,
Lee and Matan
  • 0
    Guru 10750 points

    Hi Matan,

    Are you using cache? if you are using cache try to run without it and see what happens,

    Thanks,

    HR

  • 0 in reply to HRi
    Prodigy 175 points

    HRi said:

    Hi Matan,

    Are you using cache? if you are using cache try to run without it and see what happens,

    Thanks,

    HR

    Hello HR and thank you for the quick reply.

    We are using the cache and will try to run without it like you suggested and will report back.

    Can you please explain why you suspect the cache is the problem? 

    Matan

  • 0 in reply to Matan Aloni
    TI__Mastermind 20790 points

    Matan,

    DMA Buffer handling for Ping-Pong Operation:

    The EDMA paRAM sets are programmed to receive data in RX buffers and transmit data from TX buffers.
    When an RX buffer gets filled, the contents will be copied to TX buffer, then it will be transmitted.
    If no data is received, the EDMA paRAM sets for transmission are programmed to transmit from the loop buffer,
    which is a NULL buffer containing no valid audio data. And also refer the below wiki pages,

    http://processors.wiki.ti.com/index.php/StarterWare_Audio_Application
    http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL

  • 0 in reply to Pubesh
    Guru 10750 points

    Hi Matan,

    As you describe there is no issue when doing a loopback with no additional SW and you don't have timing issues so there is someone writing/changing part of your buffer's, the cache could be an issue if your buffers are in the DDR as there is no coherency between the L1/L2 and the DDR, another thing is alignment what alignmen are you using for the buffers?

    Thanks,

    HR

  • 0 in reply to HRi
    Prodigy 175 points

    Hello all,

    New and interesting info on this issue: Only when floating point operations are added to the code does the ticking begin.

    This means that when the code has no floating point operations the sound in the output is clean. But when adding floating point operations (in our case, we tried type casting int variables to float variables) the ticking returns. The added floating point operations are not related to the input/output - we just added them as a test.

    We noticed that when adding 250 FP operations or more, the ticking happens. Our buffer size is 1024, sampling rate is 24K. All the time we made sure that the processing time is much shorter then the time it takes to fill a buffer (so no RT issues here).

    Do we need to do some configuration to enable floating point operations? Is there any issue about variables types that we are not aware of?

    Do you see any reason for FP operations to cause such an issue?

    Thanks,

    Matan

  • 0 in reply to Matan Aloni
    Guru 10750 points

    Hi Matan,

    Can you put all the code/data/... in DDR and only the transmit/received ping/pong buffers in L2 (align them to 64Bytes), 

    There is no code to switch between Fix/Float, the functional units include command for both,

    Thanks,

    HR