[66AK2G02] Audio echo program with audio daughter card

Hi Rahul,

Thank you for your reply. OK, understood. I'm wondering if audio SDK is later version of PAF.  Correct ?

Best Regards,
Naoki

Hi Rahul,

Thank you for your update on this thread. Some questions:

1. The wiki is for analog in/out, so how about digital in/out ?
2. How about ARM side build option ?
3. What is the intention of the following code in audio echo task ?

		for(count = 0; count < 0; count++)
		{
			asm("* Comment to maintain loops through compiler optimization");
		}

4. I believe the following code is incorrect implementation and should be fixed. It does not meet McASP initialization sequence. The code should wait for the 1st transmit data serviced by EDMA. Please see your TRM. This potentially cause audio errors, for example, Lch can go to Rch position and vice versa in I2S format.

void Mcasp_localActivateSmFsForXmt(const Mcasp_Object *instHandle)
{
    assert(NULL != instHandle);

    McASPTxStatusSet(instHandle->hwInfo.regs,
                     ((uint32_t) MCASP_TXSTAT_XERR_MASK |
                      (uint32_t) MCASP_TXSTAT_XDMAERR_MASK |
                      (uint32_t) MCASP_TXSTAT_XSTAFRM_MASK |
                      (uint32_t) MCASP_TXSTAT_XDATA_MASK |
                      (uint32_t) MCASP_TXSTAT_XLAST_MASK |
                      (uint32_t) MCASP_TXSTAT_XCKFAIL_MASK |
                      (uint32_t) MCASP_TXSTAT_XSYNCERR_MASK |
                      (uint32_t) MCASP_TXSTAT_XUNDRN_MASK));

    /*Start the Serializer, State M/C and Frame Sync Generator                */
    mcaspBitSetGblXCtl(instHandle,
                       (uint32_t) MCASP_GBLCTLX_XSRCLR_MASK);
    mcaspBitSetGblXCtl(instHandle,
                       (uint32_t) MCASP_GBLCTLX_XSMRST_MASK);
    mcaspBitSetGblXCtl(instHandle,
                       (uint32_t) MCASP_GBLCTLX_XFRST_MASK);

}

5. The example code is not using abstracted driver interface (GIO/IOM) but using McASP API directly. In the past, TI wanted to use such higher layer for drivers (look at BIOS PSP). Do you have any plan to use such higher level API for audio examples ?

6. No guide for Mcasp_ChanParams paramters ?

Best Regards,
Naoki 

Naoki Kawada said:

1. The wiki is for analog in/out, so how about digital in/out ?

Yes, currently the package only contains example for analog IO loopback. Digital IO loopback has not yet been ported from platfom library to use the PRSDK approach. For reference, you can look at the digital loopback code here: pdk_k2g_1_0_4\packages\ti\platform\evmk2g\platform_audio_test

Naoki Kawada said:

2. How about ARM side build option ?

Currently the usecase information we have has only the DSP usecase with the audk2g daughter card. I can check the road map to see when the ARM build will be added to the driver. Do you have plans to use this driver from the ARM?

Naoki Kawada said:

3. What is the intention of the following code in audio echo task ?

		for(count = 0; count < 0; count++)
		{
			asm("* Comment to maintain loops through compiler optimization");
		}

Yes, this seems to some debug code that the developer needs to clean up. that loop should have no effect

Naoki Kawada said:

4. I believe the following code is incorrect implementation and should be fixed. It does not meet McASP initialization sequence. The code should wait for the 1st transmit data serviced by EDMA. Please see your TRM.

What Section of TRM are you referring to here. I would appreciate if you can point to what is violating the spec. From the function it appears the CPU is clearing previous transmit events and then  does frame sync and state machine reset and clears the transmit buffer. Please provide some clarification.

Naoki Kawada said:

The example code is not using abstracted driver interface (GIO/IOM) but using McASP API directly. In the past, TI wanted to use such higher layer for drivers (look at BIOS PSP). Do you have any plan to use such higher level API for audio examples ?

BIOS PSP pre-dates Processor SDK RTOS. Also, when migrating from DSP BIOS to SYSBIOS to TI RTOS, the GIO Model is severely deprecated. Please look at the Deprecated model section in Appendix E of the TI RTOS user guide:

Naoki Kawada said:

6. No guide for Mcasp_ChanParams paramters ?

The LLD driver Design document "MCASP_LLD_SDS.pdf"is provided in the docs folder pdk_k2g_1_0_4\packages\ti\drv\mcasp\docs. this provides the description of the ChanParams. there is some room for improving the documentation and the developer is currently working on it.

Regards,

Rahul

Hi Rahul,

Rahul Prabhu said:

Currently the usecase information we have has only the DSP usecase with the audk2g daughter card. I can check the road map to see when the ARM build will be added to the driver. Do you have plans to use this driver from the ARM?

Not sure but some customers may want. I think it is good to have ARM build option for future extension.

Rahul Prabhu said:

What Section of TRM are you referring to here. I would appreciate if you can point to what is violating the spec. From the function it appears the CPU is clearing previous transmit events and then  does frame sync and state machine reset and clears the transmit buffer. Please provide some clarification.

It seems the description for McASP initialize sequence has been deleted from K2G TRM. I assumed the almost same description just like below (It is TRM for C6748) must be existing in K2G TRM.

23.0.21.1.2 Transmit/Receive Section Initialization

The following is snippet from the document. There is no code related to the led lines in the current mcasp driver implementation.
I believe McASP IP itself is same with legacy DSP on K2G, so I think mcasp initialization sequence should still meet to this requirement.

=========================================================================
8. Verify that all transmit buffers are serviced. Skip this step if the transmitter is not used. Also, skip this
step if time slot 0 is selected as inactive (special cases, see Figure 24-24, second waveform). As soon
as the transmit serializer is taken out of reset, XDATA in the XSTAT register is set, indicating that
XBUF is empty and ready to be serviced. The XDATA status causes a DMA event AXEVT to be
generated, and can cause an interrupt AXINT to be generated if it is enabled in the XINTCTL register.
(a) If DMA is used to service the McASP, the DMA automatically services the McASP upon receiving
AXEVT. Before proceeding in this step, you should verify that the XDATA bit in the XSTAT is
cleared to 0, indicating that all transmit buffers are already serviced by the DMA.
=========================================================================

Rahul Prabhu said:

BIOS PSP pre-dates Processor SDK RTOS. Also, when migrating from DSP BIOS to SYSBIOS to TI RTOS, the GIO Model is severely deprecated. Please look at the Deprecated model section in Appendix E of the TI RTOS user guide:

OK understand. I just wanted to confirm your would not have a plan for supporting such layer. I think GIO is very clean interface for drivers, but it was very confusing for customers.

Best Regards,
Naoki

Just forgot to comment about software design guide. 
Especially, Mcasp_BufferFormat parameter is very confusing. I think it is difficult for customers to understand which parameter should be used for their mcasp use case. It good to have the description (with some figures) in software design guide.

Best Regards,
Naoki