• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 654 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

am335x mcaspPlayBk problem, I2S L/R swapped

Jason Brchan
Intellectual 260 points

I am experiencing an issue with the mcaspPlayBk example provided in the StarterWare for the EVM which provides a simple loopback of data.

I have only modified the pin muxes from the StarterWare example so the program works with McASP0 and I2C2 (instead of McASP1 and I2C1). This way I can interface the BeagleBone with the Audio Cape RevB1 (AIC3104). The program runs fine, except the L/R channels get swapped in the AM335x.

When I send an analog signal to the CODEC left channel, I can monitor the data out of the CODEC and see that the left channel data appears while the frame sync is low (as expected according to the AIC3104 datasheet for I2S). However, after the AM335x performs the copy of input data buffers to the output buffers, the AM335x outputs the left channel data while the frame sync is high, so the CODEC plays this data on the R channel.

I have double checked the I2S format settings (XFMT, RFMT) and they agree with the TRM.  Does the mcaspPlayBk example have the same behavior when running on the actual EVM?

I would appreciate any advice or assistance you could provide me!

Thanks,
Jason

  • 0
    Intellectual 260 points
    Still unresolved. I would appreciate any suggestions, thanks!
  • 0 in reply to Jason Brchan
    TI__Intellectual 1915 points

    Jason,

    @ “The program runs fine, except the L/R channels get swapped” -- I shall assume this issue apart, you're able to stream audio via McASP continuously. i.e, Pinmux for McASP0, I2C2 etc are fine, the codec clocking is fine, the EDMA runs continuously etc. Also, I shall assume that this behavior is consistent & not contingent on any other parameters.

    A few usual suspects to check w.r.t McASP are:

    • Is the AIC 3104 codec’s clock polarity setting matched by McASP’s configuration? Specifically FSRP/FSXP, CLKRP/CLKXP.
    • Since you claim to have probed the data coming IN to the McASP from the codec properly per datasheet, the next spot to check McASP config would be "Transmit Bit Stream Data Alignment" (2.4.5.1 from McASP TRM). Specifically look for bitstream order – if LSB/MSB are reversed, then the channels could be swapped.
    • Next place to inspect would be software handling of the buffer-contents (i.e, samples) exposed via the transmit buffer (i.e, in memory). You could inspect the contents of the memory on CCS memory window. <L0R0> <L1R1>.... order in the memory, with mismatched interface format could appear the other way. eg: If you see <R0L0> <R1L1>, then the LSB seems to be streamed out first (even with other I2S settings in XFMT being correct).

    Govind.