Cant get the OMAP L138 audio example to work

Hi Ricardo,

If you see in both versions of mcsdk_1_01_00_01 & mcsdk_1_01_00_02, there are external dependancies mentioned in the release notes as below:

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk/latest1/index_FDS.html

External Dependencies:

CCS version 5.4.0.00091

Arago Toolchain for ARM platforms

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

I think, it would be advisable to install CCS to the  mentioned version 5.4.0.00091above and arago tool chain is also available for ARM platforms from the above link.

I think, MCSDK ver. 1.1.00.02 is the first GA release and do not have any known issues.

Thanks & regards,

Sivaraj K

Thanks for your quick answer,

 

On your answer you are talking about the MSDK, (even the link talks about the MSDK), and the example we are working on is from the PDK. Is, what your are talking about, valid for both the PDK and MSDK? Or are them different scenarios?

Thanks in advance

Hi Ricardo,

PDK is part of MCSDK installation.

The answer addressed by me in my previous post is valid for both PDK and MCSDK. They are not different scenarios and they both are same.

After MCSDK installation, it will create a folder named "PDK" which is the one i am talking about.

Thanks & regards,

Sivaraj K

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

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

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

Ok, thanks for that Data. Now we understand what you are telling us. We have only 1 problem. When we want to download the Arago toolchain,from this link http://software-dl.ti.com/sdoemb/sdoemb_public_sw/arago_toolchain/2011_09/index_FDS.html we have found out its only available for Linux... Is there a Windows version? Do we need to install this even if we are using the DSP instead of ARM?

Thanks

Hi Ricardo,

Thanks for your update.

There is no windows version of arago tool chain and it is applicable only for Linux. You need to think of only CCS version 5.4.0.00091 reg. external dependancies.

Thanks & regards,

Sivaraj K

 

Hi, thanks for your answer.

Is there any documentation or procedure that specifies how to get to know the external dependencies for this example? As it compiles well, we dont know what we are missing, and werent able to find it on any guide.

 

Thanks in advance,

Ricardo

Hi Ricardo,

Please check the MCSDK release notes.pdf from the below MCSDK product downloads to check for external dependancies:

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk/latest1/index_FDS.html

Also, please refer the below wiki's for loading and runnings DSP example projects:

http://processors.wiki.ti.com/index.php/MCSDK_OMAPL138_User_Guide_Chapter_Exploring#DSP.C2.A0example_projects

http://processors.wiki.ti.com/index.php/MCSDK_OMAPL138_User_Guide_Chapter_Tools#Loading_and_Running_DSP_applicaton

Thanks & regards,

Sivaraj K

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

 

Hi,

We had already checked this references, before creating this post. We have also checked that we have the last version of MCSDK. Our Code Composer Studio version is 5.5.0.00077. So, to sum up, we have bought 5 kits (Omap TMDXLCDK138), tested two of them, with 2 different computers, and the example application that comes for the MCASP included on the software distributed by TI wont work. We dont seem to be able to find technical support anywhere, so we would like to know if these example proyects actually work, and if you could test them.

We need this to start working on a proyect, to design a custom board. We have been developing for 5 years, since the family of C5502, producing more than 100 boards a year. Then we migrated to C6472 and C6678. With our experience working with TI, we havent been able to solve this problem, and thats why we insist with this question. We have a schedule to follow, and we cant keep losing time on this stage, because the audio part of the project only represents 20% of all that has to be done.

I hope you can understand our persistence with this subject, and provide us with a proper solution.

Regards

Ricardo Leber

Hi Ricardo,

W apologise for the cause.

What exactly the problem you are getting when you build the McASP example application which comes along with MCSDK? Could you give us more details on your error? Are you getting issue in building or loading the image into the board? Also, try to debug the code where exactly code got hanged. If possible, could you please give us the McASP register dump.

We would try to reproduce the issue which you were getting in MCSDK package, if you give us all the details. If it is a valid bug in the McASP example application, we would file an IR for that.

Thanks & regards,

Sivaraj K

 

 

Hi, thanks for your quick answer.

First of all, we dont have any problem at all neither building the application nor loading the image. We can debug the program step by step, and what we have noticed is that we never enter the function

void mcaspAppCallBack(void* arg, MCASP_Packet *ioBuf)

So the semaphores Semaphore_post(semR) and Semaphore_post(semT) are never executed, so the program stays locked on the

472 Semaphore_pend(semR, BIOS_WAIT_FOREVER);

line, from the following function

void Audio_echo_Task() function

as shown on the image we are attaching.

We have noticed that the registers from the McASP are all in 0, meaning that the peripheral is powered down.

We are working on the following path

ti\pdk_OMAPL138_1_01_00_02\packages\ti\drv\exampleProjects\MCASP_AudioExampleProject

We are attaching an image of the place where the program gets stuck, as well as the registers dump.

 

5482.register_audio_example.txt

 

Thanks for your help, let us known if you need further information of our problem.

Regards,

Ricardo

Hi Ricardo,

Let me check whether the issue is reproducible from my end and will get back to you.

Thanks & regards,

Sivaraj K

Hi Ricardo,

Basically, Tasks/Threads will run concurrently on a priority basis on a BIOS scheduler but one at a time which means, tasks will run infinitely in a while() loop. Acutally, debugging a SysBios application with multiple TI-RTOS kernel tasks running on a BIOS scheduler and synchronization, you need to understand how the tasks & semaphores are configured in the BIOS scheduler and need to identify how tasks are prioritized with in the BIOS scheduler.

Tasks are usually enabled to run by posting a semaphore designed to run concurrently and semaphore_pend() call is basically a blocking function call which pauses and waits for data since it has up to 32 priority levels in handling multiple tasks in the scheduler. Usually taskFxn() ( in your case it is "Audio_echo_Task") will be always alive since it runs in a while ('condition') processing loop and semaphore_pend() calls in the code waiting for the resources to be available to post the semaphore so that, the corresponding task will be ready to run in Bios scheduler. I mean, if the semaphore is not going to post yet, it is going to block and wait for the resources in the Bios forever until it gets all the resources to post the semaphore to execute a particular task.

This is the reason, you are seeing the semaphores Semaphore_post(semR) and Semaphore_post(semT) are never executed, so the program stays locked on the Semaphore_pend(semR, BIOS_WAIT_FOREVER) since it is waiting for the system events like interrupts/ISR, to occur and necessary resources to be available to post the semaphore for a particular task to be run in the bios scheduler. So, basicallty, since the tasks are running in a while loop infinitely, the timing is not synchronized for you to observe when the tasks are getting run by posting the semaphore and when it is waiting for the resources to post the semaphore  through semaphore_pend() call.

In your case, basically it's a timing issue which is not synchronized with the scheduled tasks to run on bios scheduler and it is waiting for a semaphore to get for all possible resources to post a semaphore which will execute a task promptly. So, you have to debug the Sysbios application where it gets blocked to post a semaphore in a priority based Bios scheduler. Otherwise, please have a free run on the debugger with out break points by loading the application binary & test the output audio stream thru. LINEOUT by providing input stream through LINEIN and check whether you face any issues or not.

To know more on debugging Sysbios application, please go through the SysBios software resource wiki in one shot as below:

http://processors.wiki.ti.com/index.php/Category:SYSBIOS

To understand how tasks are configured and prioritized in bios scheduler, please see Chapter 8 on the online wiki video download link, which is part of TI RTOS kernel workshop video tutorial as below:

http://processors.wiki.ti.com/index.php/TI-RTOS_Workshop

Thanks & regards,

Sivaraj K

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

 

Hi,

Thanks for analyzing our problem. We have carefully followed your instructions to test the example, and the result was the same. We went a step further, and we measured the audio interface between the Codec and the DSP with a digital oscilloscope, and we have found the following values.

-AIC_WCLK (tied to WCLK of the Codec and AFSX/GPIO0[12] of the DSP): 48KHz signal (1 WCLK pulse width, DSP mode)

-AIC_BCLk (tied to BCLK of the Codec and ACLKX/GPIO0[14] of the DSP): 1536KHz clock compatible with a stereo 16 bit tansmission

-AXR14 (tied to DOUT of the Codec and AXR14 of the DSP): Data that varies with the imput analog audio of LINE IN.

-AXR13 (tied to DIN of the Codec and the AXR13 of the DSP): Constant low value (0 volt)

According to this measures, we have concluded that the Codec is well configred, but the McASP of the DSP isnt configured at all. Please note that on the register dump we uploaded last post, ALL of the registers of the McASP are at 0 (including, the REVID). This demonstrates that it is still powered off.

 

Regards,

Ricardo

Hi,

We would like to know if theres any news with this subject. We still havent recieved any help to make the example work, and we need to progess with our project.

Thanks

Ricardo

Hi,

I think, you have the debug the Sysbios code and check where the code is hanged and you have to give us more details why the McASP registers are showing all zeros. Also, please provide us the codec register dump and validate the codec register configuration in the bios code using AIC3106 codec datasheet.

Please ensure whether the AIC Codec receives the audio data from LINE IN and probe it through oscilloscope on the corresponding pins and if so, check whether the Codec is triggering an interrupt to McASP and see whether the audio data comes into XRBUF of McASP and please ensure whether the Tx. & Rx. serializer pins (AXR's) of  McASP are mapped appropriately in the code. Please probe the corresponding serializer pins to check the McASP Tx. and Rx. data.

I don't think, there shouldn't be any issues in running the McASP_AudioExampleProject in the pdk_OMAPL138_1_01_00_02 (part of MCSDK package)

Kindly validate the above points and provide us more details on the requested inputs.

Thanks & regards,

Sivaraj K

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

Hi,

• "check where the code is hanged"
  
  As it has already been posted (MAY 21), the program gets stuck on line 472, which says:
  472 Semaphore_pend(semR, BIOS_WAIT_FOREVER);
  from the function void Audio_echo_Task();

 

• "please provide us the codec register dump, validate the codec register configuration in the bios code using AIC3106 codec datasheet"
  
  In order to do that, we need to read those registers using I2C, modifying the program. Our intention is not this, we want to run the example as it is. Anyway the values should be written on the example code
  
  
• "Please ensure whether the AIC Codec receives the audio data from LINE IN and probe it through oscilloscope on the corresponding pins"
  
  We have already done that, and we have already measured it with a digital osciloscope. As the post of 23 May states, we measured data that varies with the imput analog audio of LINE IN. Measured at AXR14 (tied to DOUT of the Codec and AXR14 of the DSP):
  
  
• "check whether the Codec is triggering an interrupt to McASP"
  
  No it doesnt, we believe that this is beacause the whole peripheral is powered down.

 

• "and see whether the audio data comes into XRBUF of McASP"
  
  We cant see anything because the whole peripheral is powered down, We only read 0.

 

•  "ensure whether the Tx. & Rx. serializer pins (AXR's) of  McASP are mapped appropriately in the code."
  
  Through the register PINMUX0 and PINMUX1, we see that the Tx & Rx serializer pins are properly mapped to the DCP's pins. Of course the serializers are powered down.
  
  
• "Please probe the corresponding serializer pins to check the McASP Tx. and Rx. data"
  
  As posted on May the 23th, we did the following hardware measures:
  

  -AIC_WCLK (tied to WCLK of the Codec and AFSX/GPIO0[12] of the DSP): 48KHz signal (1 WCLK pulse width, DSP mode)

  -AIC_BCLk (tied to BCLK of the Codec and ACLKX/GPIO0[14] of the DSP): 1536KHz clock compatible with a stereo 16 bit tansmission

  -AXR14 (tied to DOUT of the Codec and AXR14 of the DSP): Data that varies with the input analog audio of LINE IN.

  -AXR13 (tied to DIN of the Codec and the AXR13 of the DSP): Constant low value (0 volt)

 

Thanks, let us know if you need something else.

HI,

Thanks for your update.

From our end, we didn't have any issue with MCASP_AudioExampleProject and we didn't see any problem which you are reporting.

In case, if you see the same issue still exists, please contact through TI sales team/ local FAE to check whether for any board/hw issue.

Thanks & regards,

Sivaraj K

 

Hi,

As i said before, we bought five boards, and its quite difficult for all of them to have the same problem. If you are telling me that the code works, that makes us think that there might be a problem with the project predefined symbols, or other project configurations. If you are able to make the project work, could you please pass us a zipepd copy of it? To check the configurations and compare them with ours.

Thanks in advance

Ricardo

HI Ricardo,

Thanks for your update.

It was the same MCASP_AudioExampleProject and I didn't do any modifications in the code. But, i have used mcsdk_1_01_00_01 and pdk_OMAPL138_1_01_00_01 comes as part of MCSDK 1.01 installation. You could install the MCSDK 1.01 and check the same project from the below installed path:

~\ti\pdk_OMAPL138_1_01_00_01\packages\ti\drv\exampleProjects\MCASP_AudioExampleProject\

Also, as mentioned in the MCSDK Release notes, i have used Code Composer Studio Version: 5.4.0.00091 as external dependancy

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk/latest1/index_FDS.html

Note: Please install Code Composer Studio before installing MCSDK package.

With the above CCS version 5.4.0.00091 and MCSDK 1.01, i didn't see any issue in MCASP_AudioExampleProject as you report.

Please try to use the same version of CCS & MCSDK as mentioned above and try figure out whether it is a board issue of MCSDK software release issue.

Thanks & regards,

Sivaraj K

 

Hi,

On a previous post we made about the same subject, you claimed that it wasnt neccesary to downgrade to the pdk_OMAPL138_1_01_00_01 version. (http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/337338/1178723.aspx#1178723)

"Hi Ricardo,

Thanks for your update.

It is not required to downgrade to pdk_OMAPL138_1_01_00_01, you can work with current newer version of PDK, no issues.

Thanks again.

Regards,

Sivaraj K"

I also cant understand why, TI support, doesnt work with the latest versions of their products.

We are getting quite frustrated with the poor support we are recieving and how, having bought 5 kits, and having tested them on 2 different computers with an example provided by TI itself, we cant get it running.

Looking forward to a solution to this problem.

Regards,

Ricardo

 

Hi Ricardo,

Sorry, I didn't read the entire discussions on this post and just I read your initial question that you are not able to debug the McASP code.

We are trying to run and debug the MCASP_AudioExampleProyect over a OMALL138 LCDK. We can compile it and debug it without a problem, nevertheless it doesnt work.

Don't try "step by step" debugging and just click green 'run' button to run audio app.

Are you facing a problem only when you are debugging code and you are not getting problem when you just  do a simply run ?

I will look into this problem and will update tomorrow.

Hi Ricardo,

Currently, i have tried running McASP audio example project from MCSDK's, pdk_OMAPL138_1_01_00_02 but after loading the application image to the dsp core, it actually runs automatically instead of manually running the code via run button and this shouldn't be the normal case. I am currently working on it to find the cause of the same.

But for time-being, you could try McASP audio loopback example project from BIOS PSP 01.30.00.06 and you could download the same from the below link:

http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/index.html

The above bios psp supports both omapl138 & c6748 devices and you could see the McASP example project from the below path after installing the bios psp:

~\ti\BIOSPSP\packages\ti\pspiom\mcasp\build\OMAPL138\ccs4\

Also, you could try the OMAPL138 starterware package to try McASP audio loopback example project from the below path:

http://software-dl.ti.com/dsps/dsps_public_sw/c6000/starterware/01_10_04_01/index_FDS.html

http://processors.wiki.ti.com/index.php/StarterWare_01.10.01.01_User_Guide#Example_Application_9

After installing the OMAPl13x starterware package, you could see the McASP audio loopback example project from the below installed path:

~\ti\OMAPL138_StarterWare_1_10_03_04\build\c674x\cgt_ccs\omapl138\lcdkOMAPL138\mcasp\

Please try out the above options to run McASP audio example project from the OMAPL!38 Starterware/BIOS PSP package.

Thanks & regards,
Sivaraj K

 

 

 

Hi Ricardo,

We didn't receive any update from you, but still, we would wish to inform you that, McASP audio example demo works "as-is" perfectly fine with out any modification in the 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).

Both the above mcsdk versions (1.1.0.1 & 1.1.0.2) of McASP audio example 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.

So, I would suggest you to downgrade the CCS version from 5.5 to 5.4, install and try the same demo.

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 running the demo "as-is" with out any modifications in the code.

Please let us know your update on the same.

Thanks & regards,

Sivaraj K

Hi,

Thanks for your answer. So far, we always connected directly to the DSP, we never connected to the ARM first. We have never found any problem with much simpler programs, nevertheless we are going to try what you recommended. We will keep you updated. Thanks in advance
Regards

Ricardo

 

Hi Ricardo,

Yes. I'm also not able to run "McASP" code on CCSv5.5 but it works CCSv5.4 successfully and able to debug (step into & step over).

Please let us know the results.

Hi,

Is there any easy example of the McASP and EDMA working, and that can be debugged, for CodeComposer v5.5?

Thanks in advance!

Hello Ricardo,

were you able to figure out why the McASP is powered down? Did you find any solution to this problem?
I am also trying for some time now to build the MCASP_AudioExampleProject from the pdk_OMAPL138_1_01_00_02 (mcsdk_1_01_00_02) package and got the same problem (McASP powered down). I am using the ccs5.4.0.00091 for linux (Ubuntu 12.04LTS).

I would very much appreciate if you could help me.

Thanks and regards,

Laura S.