I built a cape using the same codec as the BB Audio Cape Rev B (tlv320aic3104) =, and wired it up the same way to reduce the amount of Linux configuration I'd have to do to get it to work. I finally have it communicating over the i2c bus, and both the codec and the alsa sound card seem to be (mostly) properly configured in the device tree overlay (https://github.com/JetForMe/podtique/blob/v1/bbb/cape/Podtique1/BB-ENABLE-PRU.dts).
But the McASP part of the interface still seems to do nothing. Looking at the pins with an oscilloscope, nothing comes out. I *think* I'm at a point where my ALSA configuration is wrong, but I'm not sure.
Lending further credence to the ALSA config culprit theory is the fact that the i2c commands to configure the codec seem to be incorrect. In particular, when I run "speaker-test", the i2c commands that get sent to the codec set it up for DSP mode, not IIS/I2S mode. The DT overlay calls for IIS mode.
Other parts of the DT overlay seem to be working very well. Linux enables the power regulators for the CODEC via a GPIO, and takes it out of reset via another GPIO before communicating with it. I watched the I2C traffic with an I2C protocol analyzer, and it looks solid (you can see it here. The first part is the cape enumeration, the codec comms start at transaction 49: http://pastebin.com/2VFPVBbq).
On my board, I've got the differential line out L&R going to an on-board audio power amp. I haven't routed any of the other outputs (or inputs) from the CODEC.
Anyone got any insight as to why
A) the McASP pins never do anything
B) the I2C commands to the CODEC set DSP mode, not IIS mode
Thanks!
B) the I2C commands to the CODEC set DSP mode, not IIS mode
Because the default codec is doing 2 channel TDM, not 2 channel i2s.
A) the McASP pins never do anything
You have looked at the pins on an analyzer?
Thanks for the response, Jesse!
B) the I2C commands to the CODEC set DSP mode, not IIS mode
Because the default codec is doing 2 channel TDM, not 2 channel i2s.
Ah. The DT overlay is configuring McASP for IIS, but not the TLV? Where is the TLV's configuration set?
A) the McASP pins never do anything
You have looked at the pins on an analyzer?
I don't have a proper IIS analyzer, but I probed the pins with an oscilloscope, and they never change state.
Ah. The DT overlay is configuring McASP for IIS, but not the TLV? Where is the TLV’s configuration set?
In the TLV audio driver. The driver is setting the codec to 2 channel TDM. Which really is the same thing as i2s which is always 2 channels anyways. TDM can be much more channels if you want. Anyways.
I don’t have a proper IIS analyzer, but I probed the pins with an oscilloscope, and they never change state.
You do not need anything special for audio data, it is pretty slow anyways. So a few simple questions.
- Does the default audio cape work with whatever software you are running on your BBB?
- Check MCLK, BLCK, WCLK and the i2s/TDM RX/TX data with your scope with the default audio cape, what do you get?
- Then with your audio cape check MCLK, BLCK, WCLK and the i2s/TDM RX/TX data with your scope again. What is the result?
Last I worked on a custom audio cape for BBB I started with a working regular audio cape and went from that with a break out board:
https://dl.dropboxusercontent.com/u/82765462/LPAX/IMG_20150928_010158676.jpg
-Jesse
> Ah. The DT overlay is configuring McASP for IIS, but not the TLV? Where is the TLV's configuration set?
In the TLV audio driver. The driver is setting the codec to 2 channel TDM. Which really is the same thing as i2s which is always 2 channels anyways. TDM can be much more channels if you want. Anyways.
I saw in the code where it was setting it, but it's based on a "fmt" value that gets passed in from somewhere. Anyway, you're saying it doesn't really matter, so I'll ignore that particular discrepancy for now.
> I don't have a proper IIS analyzer, but I probed the pins with an oscilloscope, and they never change state.
You do not need anything special for audio data, it is pretty slow anyways. So a few simple questions.
1. Does the default audio cape work with whatever software you are running on your BBB?
I don't have a working audio cape; I've never been able to buy one (no one seems to have the Rev B in stock). I did just now try using the BB-BONE-AUDI-02-00A0.dts overlay. I get the exact same behavior.
2. Check MCLK, BLCK, WCLK and the i2s/TDM RX/TX data with your scope with the default audio cape, what do you get?
3. Then with your audio cape check MCLK, BLCK, WCLK and the i2s/TDM RX/TX data with your scope again. What is the result?
Just DC 0V on MCLK, BCLK, WCLK, DIN, DOUT. The I2C bus definitely has traffic.
You should be seeing a 12MHz MCLK coming from the BBB when properly configured and running speaker-test.
Without this the TLV will never be able to generate BCLK and WCLK and RX/TX the audio data.
-Jesse
