LCDK6748 audio problem

Hi Jouko,

Thanks for your post.

Basically, there is no relation between emulators and sampling rate. It should be with Transmit and Receive FIFO Buffers of McASP which allows to operate at higher sampling rates.

Please check the datsheet link below for C6748 and check for periheral information of McASP under section 5.15

http://www.ti.com/lit/ds/symlink/tms320c6748.pdf

Usually Transmit & Receive FIFO Buffers allow the McASP to operate at a higher sample rate by making it more tolerant to DMA latency.

Please check for the Read & wirite FIFO control and status registers which can be accessed through McASP peripheral configuration port as below:

WFIFOCTL Write FIFO control register

WFIFOSTS Write FIFO status register

RFIFOCTL Read FIFO control register

RFIFOSTS Read FIFO status register

Tha above registers are specified in table 5-51 in the datasheet link above.

Please access the above and do evaluate the same.

Hello Sivaraj,

The bug was actually quite trivial: the EVMOMAPL138 and the LCDK use different McASP channels (the former # 11 and 12, but LCDK # 13 and 14)

so it was not sufficient to only replace the initialization routines, because in the audio loops the test for XRDY was going to a wrong channel!

(which makes me wonder why I previously still got signal using the lower fs -well, too lazy to try to find out)

Thanks,

Jouko

Dear Sivaraj,

Now when I got the polling mode code working, I tried the EDMA3 based audio looping example in the same eXperimenter audio.c  software,

 in the same environment as previously described.

I could not get it working. The CPU remains in the loop waiting for the interrupt. When I check the Interrupt Pending Register,

indeed it remains not set for the ping/pong channels used, so the problem is not in the interrupt service logic, because the interrupt

request never comes.

I also checked that the clocks (MCLK,BCLK, and WCLK) are correctly output from the AIC3106 to the 6748. This is expected because the setting is the

same as for the polling mode I/O (BTW, as a sidenote, I noticed an error in the comment of the AIC settings: AIC is set as the master, not slave when outputting the

clocks). So the EDMA controller should be receiving data from the McASP. Because all these operations occur in the processor internal hardware,

it is quite impossible to debug. The example EDMA setup code in the L138_LCDK_aic3106_init.c includes some modifications from the corresponding

OMAP-L138 eXperimenter version, and I cannot find any errors in it. However, both the McASP and EDMA are so complex that it is hard to try to

check if some settings are not correct. I wonder if anybody has got the LCDK variation of the EDMA based code for the eXperimenter working?

Best,

Jouko

Hello,

I managed to get the EDMA3 audio example working by moving the code from CCSv4 to CCS5.

However, also there you need to do either power reset or disconnect target - connect target -sequence  in order to start correctly.

It is not sufficient to do only CPU or system reset + restart. In CCSv4 the same sequence does not manage to bring the example alive, it only works in CCS5.

So obviously there is something missing in the initialization sequence, or maybe some McASP underrun problem if you have

such a setup, i.e. using the slow USB100v2 emulator - CCS5 may be a little faster in starting the emulation.

I remember somebody else also had similar starting problems with the EDMA3, needing also power reset.

Regards,

Jouko