DRA76P: no data output on McASP

Hi Woj,

Where did you obtain this PDK from?  The SDK which supports PDK McASP is http://software-dl.ti.com/infotainment/esd/jacinto6/processor-sdk-rtos-automotive/latest/index_FDS.html.  I would suggest you use this as we have not supported copy/paste of BSP code into PDK.  The SDK does not support DRA76P SOC/EVM directly, but the driver and integration details are the same as on other DRA7xx devices for reference.

You may be close with your setup.  Is padconfig set up properly to output mcasp1_axr5 signal?

Thanks,
Stephen

Hello Stephen,

The IPU1 image was build from the vision sdk. As you may know, the pdk of the vision sdk environment doesn't support mcasp. So I copied the macap driver code from bsp-01.02.03.04, which has been verified in another program on the same board.

And the padconfig of the mcasp1_axr5 has been set properly too according to the value of the register CTRL_CORE_PAD_MCASP1_AXR5:

omapconf read 0x4A0036C8

00040000

Are there any other points need to be checked? I mean I'm not sure whether this issue is caused by McASP itself or by EDMA3.

Thanks,

Woj

Hi Woj,

I need to get more information before I can understand what the problem may be.

Woj said:

I copied the macap driver code from bsp-01.02.03.04, which has been verified in another program on the same board

What program did you use to verify this?  The log showing buffer submission for EDMA copy in your new program seem odd for I2S configuration.  Are there differences between McASP/EDMA configurations and program flow between the working and non-working applications?  

Also, I see you are using omapconf tool - which OS are you running on A15?

Thanks,
Stephen

Hello Stephen,

Stephen Molfetta said:

What program did you use to verify this?

It was verified on APPE SDK(vis_01.50.23.01) which runs on the DSP core.

Stephen Molfetta said:

The log showing buffer submission for EDMA copy in your new program seem odd for I2S configuration.

Don't understand of this question.

Stephen Molfetta said:

Are there differences between McASP/EDMA configurations and program flow between the working and non-working applications?

The configuration of McASP is copied from the APPE program, as a comparison, the dumped values of the McASP registers when running APPE program is listed here(both transmit and receive are enabled on APPE program): /cfs-file/__key/communityserver-discussions-components-files/791/mcasp_2D00_dsp1.txt

Regarding the configuration of the EDMA, only the DMA request channel is change from 1 to 59, since the lower channels are assigned to A15 in the vision SDK. 

And the program flow of my new program is a simple version copy of the APPE program, generally described as below:

1. Call GIO_issue() twice before the first DMA interrupt coming, then wait for the next interrupt in the main loop.

2. Call GIO_reclaim() in the callback function called by the DMA ISR, and send a message to the main loop.

3. The main loop will call GIO_issue() to issue the next data package and wait again.

The log of the APPE is listed here: /cfs-file/__key/communityserver-discussions-components-files/791/mcasp_2D00_dsp1_2D00_log.txt

Stephen Molfetta said:

Also, I see you are using omapconf tool - which OS are you running on A15?

The OS running on A15 is Android O which is build from 6AO.1.1 SDK.

Hi Woj,

Thanks for providing the details.  It is helpful to know your working reference is APPE:

Woj said:

Stephen Molfetta

The log showing buffer submission for EDMA copy in your new program seem odd for I2S configuration.

Don't understand of this question.

I was looking at the BCNT/CCNT you have in your EDMA PaRAM.  Normally for I2S, BCNT is 2.  However, The BSP which is provided with APPE is a patched version with a hack to use the maximum size of McASP FIFO possible.  With that, it is more reasonable now that your BCNT is 32.  I would like to confirm whether the BSP code you copied into your PDK was taken from the 01.02.03.04_patched installer or if you obtained the BSP through another means?

Note that for APPE, GIO_reclaim can be called from the ISR context only because a SyncGeneric is specified as the synchronization mechanism when passing GIO_params into GIO_create.  This is a basic sync interface which doesn't actually use any OS semaphore or synchronization method and just unconditionally returns.  By default, GIO_params sync method will use SYS/BIOS Sempahore interface.  Did you make this similar change in your application?

APPE data flow is relatively complex, so it would also be helpful to understand the required data flow for your application.  There is a much simpler flow in the bsp_examples_audio_loopback example application provided by the BSP.  This can run both C66x_1 and IPU1 and can be used to as another reference for your implementation. Please confirm whether a similar type of program flow would be a better starting point for you?

Thanks,
Stephen

Hello Stephen,

Stephen Molfetta said:

I would like to confirm whether the BSP code you copied into your PDK was taken from the 01.02.03.04_patched installer or if you obtained the BSP through another means?

Yes, the McASP code is copied from bsp-01.02.03.04 witch is installed by bsp_setuplinux_01.02.03.04_patched.bin. Is the value 32 of BCNT being a problem, and should I change to another McASP code?

Stephen Molfetta said:

Did you make this similar change in your application?

Yes, I created the sync as APPE did.

SyncGeneric_Params_init(&syncParam);
syncParam.userSignal = (SyncGeneric_SignalFunc)mcaspCallBack;
syncParam.signalArg = (UArg)&gioHandle;
syncGen = SyncGeneric_create(&syncParam, &eb);
ioParams.sync = SyncGeneric_Handle_upCast(syncGen);

And GIO_reclaim() is called inside the mcaspCallBack().

Stephen Molfetta said:

Please confirm whether a similar type of program flow would be a better starting point for you?

My purpose is really simple, just need to implement the play/stop sound feature through the McASP with a small latency. I would like to try the flow in the bsp_examples_audio_loopback example as you suggested.

Hello Stephen,

I ported the bsp_examples_audio_loopback example into my project, unfortunately there was still not any data on axr5 pin.

My project is base on the vision sdk, the code is: /cfs-file/__key/communityserver-discussions-components-files/791/board_5F00_tda2xx_5F00_ipu1_5F00_0.c log: /cfs-file/__key/communityserver-discussions-components-files/791/mcasp1_2D00_ipu1.txt regist: /cfs-file/__key/communityserver-discussions-components-files/791/mcasp1_2D00_ipu1_2D00_reg.txt

All the work is included in the code except the edma initialization, which you can find the source code in vision_sdk\links_fw\src\rtos\utils_common\src\dma_cfg\utils_dma_edma3cc.c EDMA3_DRV_Result Utils_edma3Init(UInt32 edma3Id).

Can you please spend some time to examine my code?

Hi Woj,

What is your expected data format for your board?  You mention I2S in your original post, but the McASP configuration is not I2S.  I see the following:

• 32-bit slot size,16-bit word size, right-justified data
• 0 bit delay from the frame sync
• Rising edge of frame sync starts frame

Regardless, I would think your setup should be valid since you have rotation active, so can still get data out the pin as an effective 32-bit word.

I'm not seeing any issues with the code after looking at it for a while.  Did you say you validated APPE on your board?  Do you have a TI EVM where you can run the BSP audio example?  I'm trying to understand what else may be different to see why you don't have data on your board/serializer.

Thanks,
Stephen

Hello Stephen,

Sorry for late reply.

Stephen Molfetta said:

What is your expected data format for your board?  You mention I2S in your original post, but the McASP configuration is not I2S.  I see the following:

• 32-bit slot size,16-bit word size, right-justified data
• 0 bit delay from the frame sync
• Rising edge of frame sync starts frame

Yes, that's the expected output data format.

Stephen Molfetta said:

Regardless, I would think your setup should be valid since you have rotation active, so can still get data out the pin as an effective 32-bit word.

I changed all the sample data to value 0xFFFFFFFF, still not any data. However, when I changed the mask value, 0xFFFF0F0F for example, and set the XPAD to 0b1, then there was non-zero data output. So I think the McASP works fine, I guess the cause is the sample data provided by the EDMA, but I didn't find any proof.

Stephen Molfetta said:

I'm not seeing any issues with the code after looking at it for a while.  Did you say you validated APPE on your board?  Do you have a TI EVM where you can run the BSP audio example?  I'm trying to understand what else may be different to see why you don't have data on your board/serializer.

Yes, I have validated the APPE on my custom board, not a TI EVM. And the new project, which is build base on the vision sdk, runs on the same custom board too.

Woj said:

I changed all the sample data to value 0xFFFFFFFF, still not any data. However, when I changed the mask value, 0xFFFF0F0F for example, and set the XPAD to 0b1, then there was non-zero data output. So I think the McASP works fine, I guess the cause is the sample data provided by the EDMA, but I didn't find any proof.

According to this test, it seems that the McASP works fine, and the DATA port of the McASP is feed by the EDMA properly too. Now I'm wondering whether the EDMA got the correct source data.

The soure data buffer is allocated as shown below:

iheap = HeapMem_Handle_to_xdc_runtime_IHeap(myHeap);
Error_init(&eb);
txBuf[count] = Memory_calloc(iheap, BUFSIZE, BUFALIGN, &eb);

and myHeap is confiured in Ipu1_0.cfg like this:

var HeapParam = new HeapMem.Params;
HeapParam.size = 200000;
Program.global.myHeap = HeapMem.create(HeapParam);

Please confirm whether this method used for allocating data buffer is correct or not.

In chapter 22.1 of the TRM, it says that "MMU1 dedicated to EDMA Transfer Controller 0 (TC0), and EDMA Transfer Controller 1 (TC1)", as per my understanding, the EDMA is shared between multi remote cores(IPU1, IPU2, DSP1 and DSP2), then there must have one unified translation tables setting of the MMU1. Where does the MMU1 be configured? The environment is 6AO.1.1 + vision SDK, IPU2 is configured as the primary core in vision SDK, and my code runs on IPU1 wich is configured as the secondary core.

Hello Stephen,

Thanks for your help, no further assistance is needed on this issue.

Regarding the MMU1 setup, I'll create a new thread if necessary.