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.

MCSDK MCASP_AudioExample for EVMOMAPL138

Other Parts Discussed in Thread: OMAPL138

Hello,

I am trying for some time to figure out how to make the MCASP_AudioExampleProject (MCSDK1_01_00_02 ) work.

I am using Ubuntu 12.4LTS and CCSv6.1 for linux.

I managed to wake up the DSP, by including the EVMOMAPL138_DSP.gel file that comes with the CCSv6 package.

My problem now, is that the program hangs somewhere in an idle loop now. I have tried single step debugging and identified the function where the problem is.

BIOS_start() (in audioSample_main.c) → createStreams() (in AudioSample_io.c) → mcaspBitSetGblRCtl(Mcasp_Object *instHandle,Uint32 bitMaskVal) (in mcasp_drv.c) and at line 3439 there is the osal_Task_sleep(1) function. The first time it enters the function, it works correctly, but the second time it goes in idle loop.

Is this a known error?

Regards,

Laura

  • Hi Laura,

    Thanks for your post.

    If you check the MCSDK OMAPL138 userguide getting started, MCSDK release supports only OMAPL138 LCDK platform and not the EVM. Please check the MCSDK userguide as below:

    http://processors.wiki.ti.com/index.php/MCSDK_OMAPL138_User_Guide_Getting_Started#Supported_Devices_and_Platforms

    Also, McASP audio example demo should work perfectly fine since we have already tested the same from our end and we would be able to suceed indebugging the McASP example code for both pdk_OMAPL138_1_01_00_01 (mcsdk_1_01_00_01) and pdk_OMAPL138_1_01_00_02 (mcsdk_1_01_00_02) and the demo works fine with CCS version: 5.4 but there are issues with CCSv5.5 on free run or  debugging the code, i mean, after loading the application image, it runs automatically and the control doesn't come to the code for debugging and i belive, the code is freezing somewhere.

    As we have not tested with CCSv6 and we are not sure whether the demo works on CCSv6, but as per MCSDK release notes, there are external dependancies as below and it is recommended to install CCSv5 as per release note inorder to avoid unnecessary issues:

    • CCS version 5.4.0.00091
    • Arago Toolchain

    After you install MCSDK 1.01, please check the MCSDK relase notes on the below insallation path:

    ~\ti\mcsdk_1_01_00_01\docs\MCSDK_Release_Notes.pdf

    To set up the linux host setup, please check the below guide:

    http://processors.wiki.ti.com/index.php/MCSDK_OMAPL138_User_Guide_Getting_Started#Linux_Host_Setup

    Note: While launching CCS debugger, please ensure to connect the ARM core first to make DSP out of reset before running the code and disconnect the ARM core, Then try reconnecting to the DSP core, reload the application image and run the application. You will succeed in hearing the audio output through Line OUT, provided when there is some input stream (mp3, aac etc) feeded through Line IN. This is because, OMAPL138 is an ARM boot device where in which arm boots first with its bootloader code and then it wakes up the DSP core letting it out of reset, so that, we are allowed to connect to the DSP core and run the application on the same.

    I would recommend you to ensure the above note is properly executed before running the McASP audio example project and you could succeed in debugging the MCSDK McASP audio example code.

    Thanks & regards,

    Sivaraj K

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

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

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

  • Hello Sivaraj,

    thank you for your answer.

    I have found out where the issue is. It appears that the McASP doesn't work. I have done single step debugging in the mcasp_drv.c source code and noticed that the values in the McASP0 registers (GBLCTL, RMASK, RFMT, AFSRCTL etc) remain unchanged (default=0x0), even though they are configured in the code and normally the values in the registers should change accordingly.

    What could be the cause of this problem? Can you help me with this issue? I would very much appreciate.

    Regards,

    Laura Scurtu