• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 805 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.

Questions about Sample Code for LCDK Audio Loopback using EDMA3, Ping-Pong Buffer

MikeH
Guru 15580 points
Other Parts Discussed in Thread: OMAPL138

Sivaraj,

Thank you for the sample code for the LCDK Audio Loopback app.

I am having a bit of trouble getting it to work.

The first thing I have run into is the statement:

        if(lastFullRxBuf != lastSentTxBuf)

If I am following this correctly, you first set lastFullRxBuf = 1 in this statement:

  

  lastFullRxBuf = NUM_BUF - 1;

since NUM_BUF = 2 in this app.

And you then set lastSentTxBuf = 1 in this statement:

    lastSentTxBuf = NUM_BUF - 1;

Since lastFullRxBuf = lastSentTxBuf, the statement above never proceeds past the if statement. So BufferTxDMAActivate is never executed and the program hangs at this if statement. 

Am I interpreting something incorrectly?

  • 0
    TI__Mastermind 35645 points

    Hi,

    Thanks for your post.

    When any new buffer is received, the lastFullRxBuf will be updated in the rx. completion ISR and will not equal to the value of lastSentTxBuf, buffer is to be sent. Actually, you have to execute the code on free run (with out breakpoints) and if you check the value of lastFullRxBuf which would be 0 and again the value of lastSentTxBuf would be 1, which is not equal to value of lastFullRxBuf =0 for ever in while(1) loop.

    I have tested the same code on free run on OMAPL138 LCDK board and i didn't face any problems. Also, for your information, Since OMAPL138 is a ARM boot device which uses gel script to wakeup the DSP while launching the target debugger and also, it require board reset on every reload of program binary which then ARM takes DSP out of reset.

    Note: Board reset by default boots the ARM first and would wake the DSP out of reset thereby, for each program reload would require reset for ARM to wake DSP out of reset inorder to successfully execute the mcasp audio playback application.

    Kindly try the above sample code with the above steps.

    Thanks & regards,

    Sivaraj K

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

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

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

  • 0 in reply to Sivaraj Kuppuraj
    Guru 15580 points

    Sivaraj,

    Thanks for your follow up. The code does indeed run properly if I disconnect, then reconnect to the target before attempting to re-run the code (which re-runs the GEL script). I am also able to halt the program during debug and re-start execution. Thanks!

    I'm a bit confused since I am using the C6748 LCDK, not the OMAP L138. So I shouldn't have any wake up problems as I would with the OMAP, correct?

  • 0 in reply to MikeH
    Guru 15580 points

    Sivaraj,

    Here's another phenomenon that I don't understand. It appears that there is either an overrun or underrun in the EDMA buffering process. Below is a snapshot of an audio waveform that has passed through the LCDK using just your memcpy rx to tx buffers. I have changed the NUM_SAMPLES_PER_AUDIO_BUF to 240 so that the glitch is easier to see (and is a more reasonable value).

    The top trace shows the memcpy time (35.5us) and the frame period (2.46ms) which represents 48k*16*240 samples. Notice the glitch that happens at the center of the EDMA frame.

    It appears that the EDMA count is off by one byte, or the buffer allocation is off by one byte, or something is overwriting one byte of one of the buffers. I have seen this before in one of my other projects when my byte count was wrong. Have you listened to audio through your board? Is there a buzz?

    Any idea what's happening?

  • 0 in reply to MikeH
    TI__Mastermind 35645 points
    Mike,

    Yes, you are right. DSP would wake up by self when you use only c6748 DSP core through its appropriate gel file.

    Thanks for your update.

    Regards,
    Sivaraj K
  • 0 in reply to MikeH
    TI__Mastermind 35645 points
    Mike,

    I don't face any such audio buzz issue which you are reporting above indeed i have tested on omapL138 LCDK and listened audio which seems fine to me.

    Let me check with hardware folks on the glitch issue and if any inputs, will let you know the update.

    Thanks & regards,
    Sivaraj K
  • 0 in reply to Sivaraj Kuppuraj
    Guru 15580 points
    Thanks Sivaraj. I really don't think it's a hardware issue tho. It's as though not enough samples have been DMA'd in or out and the wrong value is being sent to the codec. The fact that it happens 100% of the time during the DMA transfer is confusing. The pulses on the top waveform indicate the beginning (rising edge) and end (falling edge) of the memcpy process, which occurs immediately upon the rx completion interrupt. So some incorrect sample value is being inserted during the DMA transfer, either on the rx or tx transfer.

    Let me know what your hardware guys come up with.