Problems with output signal quality from TLV320AIC34.

Hi Chris,

I will work with this issue and I will answer you as soon as possible.

Additionally, could you provide the TLV320AIC34 register configuration to have a better approach of this problem?

Thank you.

Best regards,

Luis Fernando Rodríguez S.

Hello Luis,

Here is the information you requested. I start with the Codec reset, so all register values should be in their power-on/reset default values. I then perform the following register writes to configure the codec:
Starting from codec reset register values, I configure the following to
set up the PLL for the Codec...
Register 0 = 0x00
Register 7 = 0x80
Register 9 = 0xC0
Register 10 = 0x00
Register 3 = 0x11
Register 4 = 0x14
Register 5 = 0x39
Register 6 = 0x40
Register 11 = 0x01
Register 101 = 0x00
// Then, I do the following register settings to enable the output...
// For Output 1, we need the following set on Codec A:
Register 7 = 0x8A (This turns on Left & Right data path)
Register 43 = 0x00
Register 37 = 0xC0 (Always have left & right enabled)
Register 82 = 0x80 (+ some attenuation to compensate for circuit problems)
Register 86 = 0x09 (When read, it should be a 0x09)
Register 40 = 0x40 (Set Common Mode voltage output to 1.5v instead
of default 1.35v. This is to compensate for a
hardware issue that will hopefully be addressed).
// For Output 2, we need the following set on Codec A:
Register 7 = 0x8A (this turns on Left & Right data path)
Register 44 = 0x00
Register 37 = 0xC0 (Always have left & right enabled)
Register 92 = 0x80 (+ some attenuation to compensate for circuit problems)
Register 93 = 0x09 (When read, it should be a 0x09)
Register 40 = 0x40 (Set Common Mode voltage output to 1.5v instead
of default 1.35v. This is to compensate for a
hardware issue that will hopefully be addressed).

Please note that my system should be sending a 20Mhz clock signal into the MCLK_A input on the codec. I'm not currently using the "B" side in my tests. Also, here is a copy of the data table I am sending to the codec to generate the "sine" output:
static const signed short sinewave2[64] = {
0, 3211, 6392, 9511, 12539, 15446, 18204, 20787,
23169, 25329, 27244, 28897, 30272, 31356, 32137, 32609,
32767, 32609, 32137, 31356, 30272, 28897, 27244, 25329,
23169, 20787, 18204, 15446, 12539, 9511, 6392, 3211,
0, -3212, -6393, -9512,-12540,-15447,-18205,-20788,
-23170,-25330,-27245,-28898,-30273,-31357,-32138,-32610,
-32767,-32610,-32138,-31357,-30273,-28898,-27245,-25330,
-23170,-20788,-18205,-15447,-12540, -9512, -6393, -3212
};

Obviously, for the IIS implementation, I'm sending each data element once for the Left channel and once for the right channel to make the 32-bit transfer. I believe I have the byte ordering correct in the data stream since the overall shape appears like a sine wave, it's just a bit jagged and noisy.

Please let me know if you need any other information or clarification.

Thanks again,
Chris.

Hello Luis,

Have you made any progress on this issue? Do you need any more information from me? Please let me know.

Thanks,
Chris

Hello Christopher,

I checked your register configuration. I noticed that you mentioned you're using a 32-bit transfer, but the register 9 is configured as 0xC0. This means that you're configuring the Codec to use an Audio data word length = 16 bits. The correct value to use 32 bits must be 0xF0. I suggest you to modify this register and see if the signal changes.

I hope this helps you. If you still have questions, please let me know.

Best regards,

Luis Fernando Rodríguez S.

Hi Luis,

Yes, it's a 32-bit transfer, 16-bits for left channel and 16-bits for right.  Does register 9 set the data width for data transfer for left and right combined (32-bits) or left and right individually (16-bits)?

Thanks,

Chris.

Hi Luis,

I made the change you suggested.  I changed the Register 9 setting from 0xC0 to 0xF0 and I saw no difference in the output.  Do you have any other ideas of what I should try?

Thanks,

Chris.

Hi Christopher,

Thank you for check my suggestion. I think that the problem is in the registers related with the Digital Audio Data Serial Interface.

I noticed that in your PLL settings, the PLL has not been enabled with the bit D7 of register 3 (PLL Programming Register A). It is strongly related with the conversion, so I recommend to check your PLL settings to be sure that the PLL is configured correctly.

I hope this helps you, if you still have problems, please let me know.

Best regards,

Luis Fernando Rodríguez S.

Hi Luis,

Thanks for the input.  You were correct, the PLL enable bit was not being set.  I took the register settings from the configuration tool and didn't realize the enable wasn't set.  I turned on that bit, and the output got better, but there's still a problem as you can see from the traces below:

There appears to be a "flatline" in the sine wave that occurs at different spots so I don't believe it's a data issue.  Is it possible that there's some sort of sampling frequency issue here?  I"m just guessing.  As I mentioned earlier, I'm trying for a 44.1khz update frequency, but they way my clocking works out on the SPI bus, I don't hit that frequency exactly.  I had the PLL set such that it was tuned for the 44.1khz according to the tool that came with the TLV320AIC34EVM kit.  Any ideas?

Thanks in advance,

Chris.

Hi Christopher,

I checked your PLL registers configuration and I obtained a Fs(ref)=52.4KHz. Could you please check your PLL registers again?

I suggest to use the next values to obtain a Fs(ref)=44.1KHz with MCLK = 20MHz.

• R = 1
• P = 1
• K = 4.5158

I hope this improves the signal. If you still have problems, please let me know.

Best regards,

Luis Fernando Rodríguez S.

Hi Luis,

Ah!  I suspect my PLL register configuration I had in place was created when I was anticipating a 16mhz input clock.  Anyway, I tried your numbers, and although better, there were still random glitches in the output wave form.  I believe this is due to a difference in my system between the theoretical Fs(ref) and the actual frequency I can manage to output my data on the SPI bus.  I have to set the bit rate on the SPI bus using a simple divider.  I was dividing my system clock by 14 to get the bit rate which yields a Fs(ref) of about 44.643khz.  My guess is that this difference in actual Fs(ref) of data being put on the SPI bus and the Codec's PLL setting is causing the problem.  I decided to try to set my Fs(ref) as close to 40khz as I could.  (20MHz / 16 / 32) = 39062.5khz.  So if I put P=1, K=4, and R=1, the TLV320AIC34EVM Evaluation tool shows a actual Fs(ref) of 39062.5 which is an exact match.  So, I plugged these numbers into the system and things settled out nicely.  Here are a couple of scope traces to show the improvement...

So, it would appear that if I have any variation between the theoretical Fs(ref) and the actual, I'm going to get glitching on the output.  I guess it makes sense since essentially what was happening was I was either putting data out too quickly and the codec was missing a sample, or I was putting the data out too slowly, and when the codec expected to see new data, it didn't have any so it just "flatlined" with whatever the last sample was.

Do you think my analysis of this is correct?

Thanks for your help on this!  It has certainly been a learning experience.

Chris.