Audio sample application for DM814x

Hi,

The sample application project is unable to find the required libraries.  Please confirm if they are trying(facing issues with) a CCS build or a command line xdc build?.

If it is a CCS build, ensure all the components are included in the project.(For example: If you expand the includes tab of the sample application project, you should be able to view all the dependant tools of the project). Please refer the top level BIOS PSP Userguide for all the dependant tools(Section - 1.1.5) Goto i2cSample project in CCS(right click) ->build properties -> RTSC

Ensure it is picking up all the tools appropriately.

If it’s a command line xdc build, ensure that the XDCPATH is set appropriately. Has the audioSample.cfg file been modified?. Ensure all the environment variables are set appropriately as mentioned in the Userguide(DM8148_BIOSPSP_Userguide).

It is unable to find BIOS, PSP, and xdc tools. Please verify their paths.

NOTE: Clean the sample application project before doing a “build project”.

Best Regards,

Raghavendra

Hello Raghavendra,

Thanks for your reply.  I created a new RTSC project and used the src and cfg files from the audio sample application.  The application built successfully.  But now when I try to run the application on the DM814x evm, I observe that the Stream_create() for "/aic310" fails. i.e,

outStreamAic31 = Stream_create("/aic310", DriverTypes_OUTPUT,&streamparams,eb);

The above function does not return.

What do you think might be the reason for this?

Thanks,

Sharath

Hi Sharath,

Any error mesage seen when it fails?. Since you are using the src and cfg files of the sample application as is, you should be able to run the appliation on one go!. Anways, have you first tried running the default binaries that comes with the PSP?. If not please try this. If this works, then your set up, EVM and GEL file config is appropriate. Generally if there is any conflict in the mcasp/codec configuration, this can happen. Also, try probing into the aic31 driver(Aic31_open() in Aic31.c) to check what exactly is causing codec channel creation failure. Refer the DM8148_BIOSPSP_Userguide(section - 6.11) for a breif description on the Audio sample application.

Best Regards,

Raghavendra

Hi Raghavendra,

The return parameter "outStreamAic31" from the Stream_create() returns NULL.  And subsequently Stream_submit() fails.

We are loading the application on DSP without booting Linux on ARM.  This is because, if linux is booted, then the gel file (DM814x_PG1.x.gel) fails to load.  We were wondering if the I2C is enabled by the audio.cfg file itself or does it need Linux running on ARM?

Thanks in advance.

Regards,

Sharath

Sharath,

Sharath Chandrashekar said:

We were wondering if the I2C is enabled by the audio.cfg file itself or does it need Linux running on ARM?

No, not at all. It does not need Linux to be running. I am coming back to my questions - Did you try running the default binaries that comes with the PSP?. And, can you please list out all the tools you are using?(Like - EDMA, bios, etc..) Also, please share the GEL file you are using. 

Best Regards,

Raghavendra

Hi Raghavendra,

We tried the default binaries on the EVM as mentioned in the "BIOSPSP DM8148 02.20.02.01 - User guide".

The ARM binaries load and executes successfully.

But as mentioned in the doc (section 1.3 : Integration guide) if we connect DSP and run the default binaries then there is no response.

The toolset we are using are:

• pspdrivers_02_20_02_01
• edma3_lld_02_11_02_04
• ipc_1_23_05_40
• bios_6_32_05_54
• xdais_7_21_01_07
• xdctools_3_22_04_46

Attached is the GEL file we are using:

PG1.0 Centaraus board

4807.DM814x_PG1.x.zip

Pls let us know if we are missing any tools.

Thanks & Regards,

Sharath 

Hi Sharath,

There is one important thing to be noted here - Please refer the DM8148_BIOSPSP_ReleaseNotes (Section - 3)

> The McASP example(sample app) is intended to be executed only on JAMR application board.

Best Regards,

Raghavendra

Hi Raghavendra,

Alright.

So whats a JAMR application board? How different is it from Centaraus PG1.0?

Do you any similar app that works on PG1.0?

I also have tried the other examples like I2C, UART. They do not seem to work on Centaraus PG1.0.

Any GEL file / tools mismatch ?

Thanks & Regards,
Sharath 

Hi Sharath,

Can you please share your e-mail id so that I can share the McASP sample app (with modified config settings) that runs/works on the PG1.0

Sharath Chandrashekar said:

I also have tried the other examples like I2C, UART. They do not seem to work on Centaraus PG1.0.

Your GEL file also, needs to be modified. Will share this too.

Best Regards,

Raghavendra

Raghavendra, I have sent you a offline message with Sharath's email id.

- Shanmuga

Hi Raghavendra,

I do not see the verify button.

Please mark this query as VERIFIED.

Thank you for all the help.

Regards,
Sharath 

Hi Raghavendra,

I am trying to modify and run this application on our custom board which is based on PG2.1.

On this board, McASP0 is connected to amplifier. Hence, I wanted to modify the application to use McASP0 instead of McASP2.

I tried changing in audio.cfg file to the mcasp0 configuration  and also there needs some changes in function "configureAudio()" in audio_evmInit.c.

such as

#define PINCTRL_MCASP2_ACLKX    (38u)
#define PINCTRL_MCASP2_FSX      (39u)
#define PINCTRL_MCASP2_AXR0     (40u)
#define PINCTRL_MCASP2_AXR1     (41u)
#define PINCTRL_MCASP2_AHCLKX   (15u)

Sharath,

Sharath Chandrashekar said:

such as

#define PINCTRL_MCASP2_ACLKX    (38u)
#define PINCTRL_MCASP2_FSX      (39u)
#define PINCTRL_MCASP2_AXR0     (40u)
#define PINCTRL_MCASP2_AXR1     (41u)
#define PINCTRL_MCASP2_AHCLKX   (15u)

 

Could you pls let me know how you arrived to these values and what else needs to be done to change to McASP0?

Please refer the section 4.3 of the document http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf, where we have 271 PINCTRL register and each one of them are used to pin mux corresponding pins. Once the PINCTRL register is selected, then select the approprite mux mode (bit 7:0).

In the above example,  "#define PINCTRL_MCASP2_ACLKX    (38u)" has been assigned, since PINCTRL39 can be used to configure the pin mux for mcasp2 aclkx pin.

Note: PINCTRL39 register needs to be configured for Mux mode '0x01' to select the mcasp2 aclkx pin.

To enable the mcasp0,

1. you need to select the appropriate PINCTRL register and its mux mode.

2. Make a call to the prcm to enable the mcasp 0,

       Prcm_ModuleClkCtrl(0, CM_ALWON_MCASP0_CLKCTRL, Prcm_moduleClkCtrl_ENABLE, &eb);

Let me know the result....

Thanks and Regards,

Sandeep K

Sandeep,

chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP2_ACLKX] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP2_FSX] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP2_AXR0] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP2_AXR1] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP2_AHCLKX] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_I2C0_SCL] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_I2C0_SDA] = 0x60001;

For the above, how is the value 0x60001arrived at?

Thanks in advance.

-Rgds

Vallabha

Vallabha said:

For the above, how is the value 0x60001arrived at?

Please refer the table 4.11 for PINCNTLx register definition in the doc http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf . The same document's, table 4.13 has the Muxmode selection for each PIN.

Regards,

Sandeep K

Hi Sandeep,

I went through the doc.

I see that the register reset value for MCA[2]_ACLKX is 0x0006 0000. And since the Mux mode for  PINCNTL39 is set, its value would be 0x01. So the resulting register reset value would be 0x00060001. Is this correct?

So for McASP0 I have used 0x00040001, but I do not get the desired result.

Let me know if the procedure is correct?

-Rgds

Vallabha

Have you tried with the value 0x60001?

Regards,

Sandeep K

Yes, I have tried that.

Does not work.

-Rgds

Vallabha 

I am using the following configuration.

#define PINCTRL_I2C0_SCL        (262u)
#define PINCTRL_I2C0_SDA        (263u)

#define PINCTRL_MCASP0_ACLKX    (16u)
#define PINCTRL_MCASP0_FSX      (17u)
#define PINCTRL_MCASP0_AXR0     (20u)
#define PINCTRL_MCASP0_AXR1     (21u)
#define PINCTRL_MCASP0_AHCLKX   (13u)

And I have the following in the configureAudio( )

chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP0_ACLKX]  = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP0_FSX]    = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP0_AXR0]   = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP0_AXR1]   = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_MCASP0_AHCLKX] = 0x60001;

chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_I2C0_SCL] = 0x60001;
chipCtrlRegs->PADCTRL.PINCTRL[PINCTRL_I2C0_SDA] = 0x60001;

Prcm_ModuleClkCtrl(prcm, CM_ALWON_MCASP0_CLKCTRL, Prcm_moduleClkCtrl_ENABLE, &eb);

configurePCF8575( );

And have set mcaspPrms.instNum to 0 in the audioSample.cfg file.

Let me know if I have missed something.

-Rgds

Vallabha

Vallabha,

Can you please describe the exact issue? Where exactly the code stops?

Is it possible to share the audio application and the pin muxing (EVM) code?

Regards,

Sandeep K

Sandeep,

We had recieved a package from Raghvendra which enabled line in and line out via McASP2 which works fine.

We are now trying to modify the same, by using McASP 0. After doing the required changes, (mentioned in the zip file that I will be sending you), we do not hear anything.

-Rgds

Vallabha

Vallabha,

I guess, you are using the DM8148 EVM.

Has AIC (codec) connected to McASP '0'? If yes, then are you using the custom borad. On DM8148 EVM, AIC (codec) is connected to McASP 2 (serializer 0, 1).

Have you step through the application to see where exactly the execution stops? Is it properly coming out of the stream_issue() and stream_reclaim() inside the for loop?

Regards,

Sandeep K

Hi Raghavendra,

I wanted to run the Audi Sample application shared by you using ELF format. But some libraries required are in Legacy COFF format like libraries (ti.psp.platforms.evmDM8148.a674) in “pspdrivers_02_20_02_01\packages\ti\psp\platforms\evmDM8148\lib”

I have downloaded the BIOS PSP 3.00.01.0 from the following link: http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/03_00_01_00/index_FDS.html

Could you pls let me know what needs to be changed for the same LineIn LineOut application to run on Centaraus board PG 1.0 using the current BIOS PSP?

Thanks & Regards,

Sharath

Hi Sharath,

The BIOS PSP 3.00.01.00 version is for the C6748 EVM. It is not supported for DM8148 EVM.

Please contact your local representative to get the latest BIOS PSP release for DM8148 EVM. As in the “pspdrivers_02_20_02_01" release, the latest BIOS PSP release (3.10.xx) also has the "play Sine tone output" audio sample application. For the LineIn LineOut (Loopback) application, modifications have to be done accordingly as it was done  for the “pspdrivers_02_20_02_01" release package.

Best Regards,

Raghavendra

Hi Sandeep / Raghavendra,

We received the BIOS PSP package biospsp_03_10_05_00.

Thank you.

I have created a RTSC project with the below source files:

• audioSample_io.c
• audioSample_main.c
• audiosample.cfg

The *.out file created works fine on the Mistral EVM PG1.0 on the DSP standalone.

Now, I have integrated this app into our main application. We faced some issue with I2C0 device already in use etc., which is fixed in our ARM appln.

Our main application is as follows:

main()

{

do {

       /* Call Ipc_start() */

       status = Ipc_start();

   } while (status != 0/*Ipc_S_SUCCESS*/);

   BIOS_start();

}

mainthread()

{

            /* Connect to remote processor */

   do {

       status = Ipc_attach (rProcId);

   } while (status < 0);

   Hwi_enable();

   Audio_echo_task();

}

The init part passes (edma3init, configureAudio and createStreams) but the control does not come out of the GIO_Reclaim () in the later part. We referred to document @

http://www.ti.com/lit/ug/spruex3k/spruex3k.pdf

section 9.3.4

which points that GIO_Reclaim() is a BLOCKING CALL and if the control does not come out, it means that the I/O packet is not processed by the driver.

This application contains the Ipc sections. DSP is loaded from ARM slaveloader. Connect the DSP.

We run ARM application and control comes to Audio_echo_task().

We would like to know how we could resolve this issue.

Is there a way to find out why its BLOCKED?

I tried using the timeout but there is failure in Reclaim and issue calls.

Is there anything wrong in using the application in the above method?

Thanks & Regards,
Sharath

Just another additional information:

I also call the prime function which primes the sine tone data in the buffers. 

In summary, Audio_echo_task is same as the sample app Audio_echo_task in the BIOS PSP package.

Regards,

Sharath

Sharath,

The GIO_reclaim() will be unblocked by calling the callback function (registered by the GIO layer with the driver) in the interrupt context.

So, it is better to check for the interrupt generation for the issued buffer (using GIO_issue()). This can be verified by putting the breakpoint in the driver ISR. 

Regards,

Sandeep K

Hi Sandeep,

I see in your application that in prime(), two buffers buf[2] and buf[3] are issued.

In the for loop, one buffer is reclimed and the issued. These two buffers are alternately issued and reclaimed.

In our application the for loop runs once successfully and the second buffer reclaim is not happening.

Could you pls elaborate the verification in driver ISR?\

Thanks & Regards,

Sharath

Sharath,

If you put the breakpoint in the function Mcasp_localEdmaCallback() in Mcasp_edma.c file. Then for each issue of the buffer from the application, this function should be invoked in interrupt context after completing the buffer. In this EDMA completion interrupt context, the issued buffer will be released from the driver and unblocks the GIO_reclaim().

So, you need to verify that the EDMA completion interrupt is getting generated or not for each of the issued buffer. This can be done by putting the breakpoint in  Mcasp_localEdmaCallback().    

Regards,

Sandeep K

Hi Sandeep,

Thank you for the explaination.

In the DSP standalone project, I was using the PSP McASP library (bios_psp_mcasp.ae674) from "biospsp_03_10_05_00\drivers\mcasp\lib\ti814x-evm\674\release".

As mentioned, to debug in Mcasp_edma.c, I replaced the library with the McASP src from the "biospsp_03_10_05_00\drivers\mcasp\src".

It was strange that the code gets blocked in the same place (GIO_Reclaim) as in our main application. This is the same issue when I integrated the audio application into our main appln. I think now there could be mismatch in the build settings. While the pre-built library works but the source added does not work.

The tools are as follows:

bios_6_33_04_39

biospsp_03_10_05_00

edma3_lld_02_11_05_02

ipc_1_24_02_27

xdctools_3_23_02_47

Which is matching the requirements for the PSP package.

I am attaching the project zip folder. Could you pls have a look and let me know if something is wrong in the build setting?

Thanks & Regards,

Sharath

Attached is the project file.

4150.McASP_EVM.zip

Sharath,

can you please share the build log?

Regards,

Sandeep K

Sharath,

Could you please try out the command line build and share the build log?

And also try out the binary built from the command line.

Regards,

Sandeep K

Hi Sandeep,

I am using the CCS IDE to build the code.

Attached are its logs. Hope this is fine.

Thanks & Regards,
Sharath7875.Logs.zip

Sharath,

As per the build log it looks like you are trying to build the audio application for the DM8148 EVM (base board).

Could you please refer the section 9.11.1.2 of the DM814x_BIOSPSP_Userguide. Where, the steps to build the application/library for DM814x EVM has been provided. Please follow all the steps to get the application binary for DM8148 EVM.

Let me know the result. 

Regards,

Sandeep K

Hi Sandeep,

On CCS IDE, I am able to build the application code and test the audio sine wave application by loading the program binary.

It works on the DM8148 EVM (base board). I am able to hear the audio from LineOut.

But when I replaced the McASP binary by the source files to debug in the driver ISR and it does not work.

So, I wanted to know the reason.

I will refer to the section mentioned by you and test the same and let you know the result.

Thanks & Regards,

Sharath

I

Sharath,

Sharath Chandrashekar said:

But when I replaced the McASP binary by the source files to debug in the driver ISR and it does not work

From the CCS project you have shared, it looks like you have linked mcasp release library while building the debug application. Can you please check this out?

I guess "it does not work" means, the audio tone is not audible at the LineOut OR the GIO_reclaim() blocks. Which one of this is happening?

By keeping the breakpoint, it is possible that you may not hear the audio tone. In this case, you can have the global counter in the EDMA callback function and it can be viewed at any point of time in the memory window or the expression window of the CCSv5.

Regards,

Sandeep K   

>> From the CCS project you have shared, it looks like you have linked mcasp release library while building the debug application. Can you please check this out?

Sorry for the confusion. The project shared is using the library "bios_psp_mcasp" and the McASP source files are excluded from the build. If you remove the library link and include these source files. The code hangs in GIO_Reclaim(). 

>> I guess "it does not work" means, the audio tone is not audible at the LineOut OR the GIO_reclaim() blocks. Which one of this is happening?

Audio tone is audible due to the sine tone being buffered in prime(). when you try to step over the GIO_Reclaim(), it hangs.

I ll try the global counter in the EDMA callback function.

Thanks & Regards,
Sharath 

If you are adding the mcasp source file into the CCS project and building the mcasp files, then you need to consider the compiler options defined in the file "biospsp_03_10_05_00\drivers\mcasp\makefile".

Regards,

Sandeep K

Hi Sandeep, 

I saw the PLATFORM specific macro which is "CHIP_DM8148" enabled. Also I added another macro called "Mcasp_LOOPJOB_ENABLED". This works and I see the GIO_Reclaim not hanging anymore. Thank you for your input.  

Could you pls tell me the significance of the macro "Mcasp_LOOPJOB_ENABLED"?

Now I can debug in the driver ISR when integrated in the main application.

Thanks & Regards,

Sharath

Hi Sandeep,

Mcasp_LOOPJOB_ENABLED is explained in the McASP driver design doc.

According to it, When the Mcasp driver is not having any pending requests and the Mcasp driver is not stopped, the loop job buffer is loaded. This means that the sine tone that is bufferred is looped when there is no pending requests.

Regards,

Sharath

Sharath,

In loop job buffer mode, the driver will send the mute buffer when there is no pending requests in the driver.

If the application does not provide the loopjob buffer, then driver uses its internal loopjob buffer (which is initialized to '0'). If application wants to provide the loopjob buffer and its content, then it can be provided through the mcasp channel parameter.

In summary, the sine tone (valid buffer) is not the loopjob buffer.

Regards,

Sandeep K

Hi Sandeep,

Thank you for the reply.

Now that I have integrated the Audio_echo_task() into my main app, still I face the same issue.

I see that the from the global counter that the EDM3_Callback is entered 4 times.

To isolate the issue, I moved the some parts of my app into your application.

Below is the flow of the code:

• Ipc_start
• Ipc_attach
• Audio_Echo_task()

I am able to load the binary through slaveloader, when I run the ARM appl (Like MessageQ), the control comes to Audio_echo_task and it hangs in GIO_Reclaim().

The same application (by commenting the Ipc_start & Ipc_attach) loaded on DSP directly, it works successfully. Also, I need to set the clock

Timer.intFreq.lo = 20000000; whereas in ARM_DSP case, I comment this from cfg file.

Now, its isolated to Ipc, GEL file (used in DSP standalone), slaveloader way.

It would be great if you could provide any pointers to this issue.

Thanks & Regards,

Sharath

What I need to know is,"Does the application Audio_Echo_task" work using the slaveloader (loading the DSP binary from ARM)?"

Is there any dependency if done this way?

Sharath,

I have not tried loading the DSP binary from ARM.

Is first GIO_reclaim() call itself getting blocked? The major reason for this to happen is the absence of the EDMA completion interrupt for the requested buffer.

You can compare the mcasp register dump using slaveloader againsts directly loading DSP binary. This would point the possible issue in configuring the mcasp, if at there is one.

Is there any change in the DSP binary between two scenarios?

Regards,

Sandeep K

Hi Ragavendra,

    Could you please share the modified Sample application and gel file as we are getting the very same error?    

Thanks & Regards

K.AmirthaRaj

Hi Ragavendra,

              Could you please update on this?

Thanks & Regards,

Amirtharaj

Hi AmirthaRaj,

BIOS PSP version 03.10.06.00 has been released. It has the sample application that you are looking for. 

Please contact your local representative to get the latest BIOS PSP release for DM8148 EVM. Please go through the Release Notes and User Guide before using the release package.

 Best Regards,

Raghavendra

Hi Ragavendra,

   Thanks for the reply,

But we are using the pspdrivers02.20.02.01 for our SDK, so it will be very much helpful for us to further work in our project. So could you please provide to us?

Thanks in Advance,

Amirtharaj