omap-l137 McAsp Rx & Edma problem.

Misha

Hello everyone,

I hope someone will help me to solve the following strange problem.

I developed a perfectly working DSPBIOS 3.3 application, where frames of 16 bits data samples were regularly acquired from McASP/EDMA through the ping pong method: McAsp Rx section had external frame & clock.

Then I tried to modify such application, in order to acquire frames of 8 bits data with the same method:
8 bits samples are regularly acquired in the expected order, but at transfer startup, the receive buffer (ping) returned by the first EDMA IRQ callback is filled with three extra zero bytes, then its three pending bytes appear on the beginning of the second (pong) buffer, then the three pending pong bytes appear at the beginning of the ping buffer, and so on.

In no way extra zero bytes are transmitted at startup to the McAsp Rx port.

Maybe McAsp or EDMA configuration problem ?

Any insight on the problem is warmly welcome.

Thank you for your attention.

over 12 years ago

0 Sivaraj Kuppuraj over 12 years ago

TI__Mastermind 35645 points

Hi Misha,

Thanks for your post.

Do you any chance of probing McASP's Rx. data thru. its appropriate serializer pins AXR[n] through scope? If you could, please probe the data pins sothat, you shall ensure whether 8-bit valid data resides in McASP's XRBUF to Rx. unit which would be serviced by DMA controller by sending DMA Rx. events. So, our idea is to confirm whether the valid data present in McASP XRBUF probing thru. AXR pins and if so then, we will later find out whether the data is being corrupted by EDMA controller either thru. software configuration or by some other means. We need to check this out if McASP do not have any issues in receiving valid data from AIC3106 codec.

Is your FIFO's enabled in the code for DMA driven data transer? Usually, McASP audio FIFO's provides additional data buffering and have greater tolerance in holding data for the DMA controller to respond to DMA requests from McASP inspite of such time variations.

Also, please check the I2S data format configuration in the code like, alignment, order, pad, slotsize, mask etc? Kindly validate the configuration in the code for any mismatch in filling three extra zero bytes & three pending bytes.

For more details on McASP setup & initialization procedue, Please refer Section 25.2.4.1 in the OMAPL13x TRM as below:

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

Thanks & regards,

Sivaraj K

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

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

Processors

Processors forum

omap-l137 McAsp Rx & Edma problem.