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.

Sample Code for LCDK Audio Loopback using EDMA3, Ping-Pong Buffer and no OS

Guru 15580 points
Other Parts Discussed in Thread: MSP430WARE, SYSBIOS, OMAPL138

Mukul,

Per your suggestion (http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/374275/1323792.aspx#1323792) I am starting a new thread on my request for sample code. I appreciate your willingness to consider providing this example code. I see this request often on the Forum and believe it would be useful to many people that want to use the C6748 for audio manipulation (self included).

The goal of the code would be to demonstrate how to configure the C6748 on the LCDK to loop incoming analog stereo audio from the audio input connector through a pseudo audio compression algorithm, to a pseudo decompression algorithm, back to the analog output connector, using EDMA3 and ping-pong buffers and NO OS (no DSP/BIOS). I need to measure the performance of the audio compression algorithm on the C6748.

Here are the specifics of what I would like to see.

1. No DSP/BIOS. No Linux. No OS.
2. Use a CSL or PSP if available (please take a look at the MSP430Ware (http://www.ti.com/tool/MSP430Ware) package as an example of what would be most helpful).
3. Include chip setup (PLLs, clocks, cache (very important for this application), EDMA, McASP, etc).
1. Send stereo analog audio to/from AIC3106. A/D and D/A set for 16 bit samples at 48000 samples/sec.
2. McASP configured similar with similar settings (16/48k stereo). Event triggers used by EDMA3.
3. Configure Ping-Pong buffers for 150 stereo samples of 16bit samples at 48k samples/sec (show that these actually need to be 32bit/sample buffers and are larger than the actual 150 sample transfer size).
3. EDMA3 input from AIC configured for transfers of 150 stereo samples to/from a ping-pong buffer with interleaved Left & Right samples (do not de-interleave).
4. If the input Ping buffer is actively receiving an EDMA transfer, send Pong samples to a pseudo audio compression algorithm (do nothing).
5. Else if input Pong buffer is actively receiving an EDMA transfer, send Ping samples to a pseudo audio compression algorithm (do nothing).
5. After compression transfer compressed samples to a pseudo audio decompression algorithm (do nothing).
7. After decompression, if output Ping buffer is actively sending an EDMA transfer to the AIC, move 150 stereo samples to output Pong buffer. Trigger on McASP Tx Event.
8. Else if output Pong buffer is actively sending an EDMA transfer to the AIC, move 150 stereo samples to output Ping buffer. Trigger on McASP Tx Event.

Please let me know if you have any questions about these requirements.

  • Hello Mike

    Thank you for taking the time to outline what you are looking for.

    I have to admit that I am not intimately familiar with the existing example that is part of the Starterware bundle but was likely developed for LogicPD EVM not the LCDK 

    Did you ever evaluate that , or would it be worth for us to port that example over to LCDK board if not available?

    http://processors.wiki.ti.com/index.php/StarterWare_01.20.01.01_User_Guide#Example_Application_8

    I want to make sure I understand what  you think is missing in the current set of examples, from your point of view (esp from a mcasp-audio codec-edma bare metal example). Was it the performance, audio delay impacts that was not acceptable? (Feel free to tell me that I missed one of the several E2E posts you highlighted in the other post - I will sieve through them)

    FYI , there was also an older audio example for c6747 , with a "graphical tool" perhaps what Louis was looking for but unfortunately is c6FLO is not supported and that was based on DSP/BIOS ( I know too many wikis and choices and perhaps meeting the requirement of what you are looking for , or not just run out of the box for c6748 LCDK) 

    http://processors.wiki.ti.com/index.php/Tuning_Audio_Latency_on_C6747 

     I do think if we do an example , it will need to be Starterware based, and I think you would be ok with that?

    Please do not consider this discussion as a commit from our side on having something available soon or near term, but this in on my radar, and I will look for constructive ways to get something out there in coming months, if the current choices are not working out. 

    Again, appreciate you putting your requirements together on a separate thread.

    Regards

    Mukul 

    P.S Also curious why no SYSBIOS etc? How does a non OS example fit in a bigger picture end application from your perspective. Are you writing your own schedulers, don't need one? (Low priority query - as i do know the benefits of starterware, but  would like to understand how it ties back to your end system etc). 

  • Mukul,

    Mukul Bhatnagar said:
    I have to admit that I am not intimately familiar with the existing example that is part of the Starterware bundle but was likely developed for LogicPD EVM not the LCDK

    I believe you are correct. I can trace it back to my old OMAPL138_StarterWare_1_10_01_01 files.

    Mukul Bhatnagar said:
    Did you ever evaluate that , or would it be worth for us to port that example over to LCDK board if not available?

    I did take a look, but at the time decided to try the DSP/BIOS approach. This led me to use:

    // Name: TTO EDMA3 LLD Example8 (Audio Pass-through example with linking/sorting)
    //
    // Authors: Scott Specker and Eric Wilbur (Technical Training Organization)
    //
    // Date: 02/17/09

    At that point in time TI was in the midst of a major upgrade in DSP/BIOS, which meant that many of the tools had compatibility and support issues. This led me to abandon DSP/BIOS altogether.

    Mukul Bhatnagar said:
    Also curious why no SYSBIOS etc? How does a non OS example fit in a bigger picture end application from your perspective. Are you writing your own schedulers, don't need one?

    I am developing real-time wireless audio devices. DSP/BIOS (or any OS) adds uncertainty into the timing equation. So I am doing my own scheduler based on a state machine and timer.

    Mukul Bhatnagar said:
    http://processors.wiki.ti.com/index.php/StarterWare_01.20.01.01_User_Guide#Example_Application_8

    I have never seen this page before. It appears to document the example in the current Starterware code. Interesting. Is it referenced on the Startware Wiki?

    Mukul Bhatnagar said:
    I want to make sure I understand what  you think is missing in the current set of examples, from your point of view (esp from a mcasp-audio codec-edma bare metal example). Was it the performance, audio delay impacts that was not acceptable? (Feel free to tell me that I missed one of the several E2E posts you highlighted in the other post - I will sieve through them)

    I believe you missed the most important thread that relates to my (and several others) frustration with the current Starterware example.

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/265165/1016397.aspx#1016397

    In this thread several very experienced people have pointed out bugs in the code and suggested changes. However, no one from TI ever acknowledged this input nor acted upon it. This is what has ticked people off.

    The other thing I want to pass along to you is this. Your statement that Starterware is released "As-is" and there is not support or updates planned, is very short sighted. When you (TI Corp) publish "Examples", we take that to mean "This is an example of how TI Corporation suggests you use our chip. This code is an example of best practices and is the correct way to use the device". But when the code obviously contains bugs, and these bugs are pointed out to you by six (or more) very smart people (as in the above thread), you or your product & marketing managers should be all over fixing these issues. The code you provides is a BAD EXAMPLE of how to correctly use the chip. Your examples should ENABLE developers, not tick them off and drive them to use competitors solutions.  /rant

    Here's what I suggest moving forward. The mcasp_c674x_c6748_lcdkC6748 is very close to what most of us are looking for. Fix the bugs in this code (per the suggestions in the above thread), change the number of buffers from 3 to 2 (currently 2 do not work properly), make it classic ping-pong (not some convoluted multi-linked (use 2 param sets, not 3), and FIX THE WARM START ISSUE (currently for every code change I make I have to terminate the debug session, cycle power to the board, then restart the debug session to make the code work. Talk about ticked off!), the FULLY TEST THE CODE before you re-release it.

    This not only applies to the McASP example, but to the entire library. If you expect developers to use Starterware as the basis of newly developed code (which I would assume is the intent of providing it), IT MUST BE FULLY TESTED, STABLE, and SUPPORTED WITH FIXES. Quite frankly, I don't know that it isn't already tested and stable, but based on my experience with the McASP example code, I am very nervous about using it as the foundation of new code, which means I would not use the C6748 device.

    I appreciate your attention to these issues and am glad that we now have your attention.

  • Mike, I don't know if it helps but I think the developer community need to pile into this thread in a big way since it seems TI has an eye on it. I wholeheartedly agree with you assessment of the 'support' for USB. Come on TI, step up to the plate and get this sorted in a professional way.

  • What I meant was support for StarterWare, not specifically USB which is my own rant subject.

  • Hi Mike 

    Thanks for taking the time to provide additional feedback on the McASP example. I will investigate what can be done to address specific short comings you have highlighted w.r.t that Audio example. 

    General outline of that example is here

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

    First order of business is likely to have this available for LCDK and look at the warm reset issue

    Just for clarity , please clarify what is your definition of warm reset and is it what is mentioned in the datasheet or something else?

    Your additional feedback is noted and forwarded internally too, although I think for now the scope of this discussion is realistically limited to what we can do with the McASP example. 

    I am not aware of any other stability issues and there is currently no plan to release the entire Starterware library with upgrades and updates for OMAPL138/C6748 family. 

    Regards

    Mukul 

  • Mukul,

    Mukul Bhatnagar said:
    First order of business is likely to have this available for LCDK and look at the warm reset issue

    I agree.

    Mukul Bhatnagar said:
    Just for clarity , please clarify what is your definition of warm reset and is it what is mentioned in the datasheet or something else?

    Several of us have experienced the fact that, after starting a debug session, connecting to the LCDK target, waiting for GEL to complete, loading the .out file, run the application, then stop running the application (suspend debugging). After stopping the program, then restarting the program from the beginning, or reloading the .out file, or even disconnecting from the target and reconnecting (triggers the GEL file) will NOT kick off DMA transfers. You must remove power from the target, reapply power, reconnect, re GEL, reload the .out file before DMA is triggered again. When "warm" restarting the program, it hangs here:

     if(lastFullRxBuf != lastSentTxBuf)

    ...which says one or more of the events is not being generated. The program hangs at this point and no DMA occurs.

    Mukul Bhatnagar said:
    there is currently no plan to release the entire Starterware library with upgrades and updates for OMAPL138/C6748 family. 

    That is unfortunate.

  • Hi Mike

    On your definition of "warm reset" , I have a better appreciation, but I don't know if this should really be on onus of the application code to do a "clean up" prior to reload/restart, more so as the EDMA does not "stop" on emulation halts, so its state-machines are active. 

    So it really does require a some sort of chip or local reset to "clean up" the events etc for the EDMA state machine and McASP even/fifo flush etc to start back in a clean state. 

    This can be managed by something like a GEL file (not in the example application IMHO), but I would think this should also work (or worked around) with CCS System Reset feature

    http://processors.wiki.ti.com/index.php/System_Reset_(Emulation)

    I think this works with both XDS510 and XDS560. 

    Have you tried this? 

    Regards

    Mukul 

  • Hi

    I'd like to add my vote to the request for better example code, having struggled with all of the issues that Mike mentions. At first I thought I was alone - now I'm wondering just how many other people must have spent days trying to figure out these problems.

    On the warm start issue: I have discovered that it's enough to do a system reset (one of the drop-down buttons - forget which, sorry), exit the debug perspective (red square button) and restart debugging (green beetle button) without cycling power. Still a real pain in the gronnies though. There must be a way to programmatically reset the DMA state machine, or whatever is required to get it going again, and there is a genuine need for this. If the released program ever gets stuck and the watchdog bites, I need some code that will recover and resume without having to ask the user to cycle power.

    So please, if you possibly can, address these issues.

    Thanks

    Roy

    esaelp ,esaelp oS

  • Mukul,

    Mukul Bhatnagar said:
    This can be managed by something like a GEL file (not in the example application IMHO),

    Really? What about .....

    void McASPTxReset(unsigned int baseAddr)
    {
    HWREG(baseAddr + MCASP_XGBLCTL) = 0x0;
    }

    ...and

    void McASPRxReset(unsigned int baseAddr)
    {
    HWREG(baseAddr + MCASP_RGBLCTL) = 0x0;
    }

    Shouldn't there be a similar "hardware reset" driver function for the EDMA3 controller?

    Mukul Bhatnagar said:
    CCS System Reset feature

    Mukul Bhatnagar said:
    Have you tried this? 

    Yes, this does work if done it the proper order.

    1. Suspend Debug

    2. Execute a System Reset from the debug drop-down menu.

    3. Re-run one of the Frequency Settings scripts from the Script drop-down menu.

    4. Reload the .out file.

    5. Resume debugging.

    But shouldn't there be an EDMA hardware reset in the library code?

    Also, as mentioned in the other thread, there is an issue with the number of bytes per transfer. My measurements of the transfer time appear to be off by a factor of 2 (too short). Can  you take a look at the comments by Elliott and Roy and let us know if there is a discrepancy?

    Please take a look at the below default PaRam settings and see if you agree that these are correct for transferring NUM_SAMPLES_PER_AUDIO_BUF .

    static struct EDMA3CCPaRAMEntry const txDefaultPar =
    {
    (unsigned int)(EDMA3CC_OPT_DAM | (0x02 << 8u)), /* Opt field */
    (unsigned int)loopBuf, /* source address */
    (unsigned short)(BYTES_PER_SAMPLE), /* aCnt */
    (unsigned short)(NUM_SAMPLES_LOOP_BUF), /* bCnt */
    (unsigned int) SOC_MCASP_0_DATA_REGS, /* dest address */
    (short) (BYTES_PER_SAMPLE), /* source bIdx */
    (short)(0), /* dest bIdx */
    (unsigned short)(PAR_TX_START * SIZE_PARAMSET), /* link address */
    (unsigned short)(0), /* bCnt reload value */
    (short)(0), /* source cIdx */
    (short)(0), /* dest cIdx */
    (unsigned short)1 /* cCnt */
    };

    /*
    ** Default paRAM for Receive section.
    */
    static struct EDMA3CCPaRAMEntry const rxDefaultPar =
    {
    (unsigned int)(EDMA3CC_OPT_SAM | (0x02 << 8u)), /* Opt field */
    (unsigned int)SOC_MCASP_0_DATA_REGS, /* source address */
    (unsigned short)(BYTES_PER_SAMPLE), /* aCnt */
    (unsigned short)(1), /* bCnt */
    (unsigned int)rxBuf0, /* dest address */
    (short) (0), /* source bIdx */
    (short)(BYTES_PER_SAMPLE), /* dest bIdx */
    (unsigned short)(PAR_RX_START * SIZE_PARAMSET), /* link address */
    (unsigned short)(0), /* bCnt reload value */
    (short)(0), /* source cIdx */
    (short)(0), /* dest cIdx */
    (unsigned short)1 /* cCnt */
    };

    Thank you for your continued support.

     

  • MikeH,

    MikeH said:
    Shouldn't there be a similar "hardware reset" driver function for the EDMA3 controller?

    Whether there should be or should not be, there is not a reset bit in the EDMA3 module.

    MikeH said:

    (unsigned int)(EDMA3CC_OPT_DAM | (0x02 << 8u)), /* Opt field */
    (unsigned int)(EDMA3CC_OPT_SAM | (0x02 << 8u)), /* Opt field */

    Do not use SAM & DAM set to 1. In the EDMA3 User Guide section "Constant Addressing Mode Transfers/Alignment Issues", there is a Note that includes

    "On the C674x/OMAP-L1x processors, no peripherals, memory, or memory controller support constant addressing mode."

    There is not enough information to say whether your EDMA configuration is "correct for transferring NUM_SAMPLES_PER_AUDIO_BUF".

    Regards,
    RandyP

  • RandyP,

    RandyP said:
    Do not use SAM & DAM set to 1. In the EDMA3 User Guide section "Constant Addressing Mode Transfers/Alignment Issues",

    This code is straight out of YOUR mcaspPlayBk.c example code. 

    RandyP said:
    There is not enough information to say whether your EDMA configuration is "correct for transferring NUM_SAMPLES_PER_AUDIO_BUF

    All of the information is included in your example code.

    Randy, sorry to see that you are now as ticked off as we are (we had such a good relationship back in the day http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/p/71605/262295.aspx#262295). My only point is that your example code should be a guide for us to use as a basis for our code development. When we have to spend hours debugging the example, it defeats the purpose of providing the example. If you don't plan to support the code, don't post it.

    Unfortunately, I will be signing off of this thread and moving on to a competitive product.

  • Mike

    Thanks. I did look through the various Starterware releases for OMAPL138/C6748, it does appear that we messed up and still have SAM/DAM set for FIFO mode in these examples. I don't think this is the case with SYSBIOS or Linux driver examples (will double check).

    I also do not see this issue with AM335x Starterware , which was done after these devices and better supported. 

    I will continue to scope on what tactical fixes we can make for this audio application example available as part of C6748/OMAPL138 Starterware example for LCDK, based on your feedback. I am not aware of too many other issues with other peripheral Starterware examples in the release, they might not have a "bug fix/enhancement" roadmap, but the team monitoring these forums does try to guide most of the queries around Starterware for these devices. 

    Regards

    Mukul

    PS: FWIW I have known Randy for years and it is not not easy if not impossible to tick him off. He is a great field apps who has been magnanimously helping on the entire E2E community and factory apps across support issues, most of the times above and beyond the call of duty, based on the wealth of experience he has garnered supporting tough customer issues. So rest assured he is not ticked off or anything.  

  • Hello Mike,

    As per your request, please find attached the c6748 starterware example code with two buffers (ping, pong) on both tx. and rx. side and accordingly, configure ping pong buffers for 150 stereo samples of 16 or 32 bits/sample

    Kindly test the EDMA ping pong buffer code and let us know your inputs on the code.

    Buffers used in the code are rxbuf_ping, rxbuf_pong, txbuf_ping, txbuf_pong and please check it.

    4784.OMAPL138_StarterWare_McASP_EDMA_PING_PONG.zip

    Thanks & regards,

    Sivaraj K

  • Sivaraj,

    Thank you for this effort. Unfortunately, as mentioned above I have decided to move to a competitive product from ADI. I hope to be in a position to try this sample code at some point in the future. However, I am sure it will be helpful to the many others who have been looking for this type of solution.

     

  • Sivaraj,

    I am on a new project that can use this code. I'll start a new thread with my questions.

    Thanks,

  • Hi Sivaraj,

    I tried to build your project.

    I get this error:

    >> Compilation failure
    subdir_rules.mk:23: recipe for target 'edma.obj' failed
    "../edma.c", line 117: error: identifier "SOC_EDMA3_NUM_DMACH" is undefined

    Do you know what's the problem? Is there a lib file that should be included?