TLV320DAC3100: I2C communication failure after configuring

Hi Derek,

First I would try to isolate SPKVDD change, one thing you can try is to initialize the device but without powering up the Class-D, ie. comment this line from your code:

  0x20, 0x86,   // power-up class-D

If you're able to communicate through I2C by doing this, we could relate it to the speaker driver.

Additionally, you can read back flag registers (register 44 to 46 on page 0) before and after initialization. Would help to check if device is detecting any issue by itself.

Best regards,
-Ivan Salazar
Applications Engineer

Hey Ivan,

Thanks for your reply. I read this after finding what I believe to be the issue. I noticed "rounded" edges on my I2C SCL and SDA signals and reduced the I2C clock from 400 KHz to 100 Khz and this mitigated my I2C issue. I no longer receive NAK's from the DAC3100 and can read all registers after configuring including enabling the class D amplifier. This leads me to believe a stronger pull-up is needed or I2C peripheral timing needs to be adjusted (DAC3100 is interfaced with a STM32L4 MCU). Strange how this would only be an issue after DAC3100 configuration.

I have a new issue now. The speaker audio output is essentially a few squeaks and is unrecognizable. Ie, it is noise. I have compared the clocks between the old hardware and new hardware and compared I2S data and they are the same.

The slight difference in clock frequencies could potentially be attributed to crystal tolerances.

For reference, here is a screenshot of my I2S data:

It has the following configuration:

Frame Length: 32 bits (16 bits per channel)

Audio file (.wav): 44.1 KHz, Stereo, 16-bits per channel

I also read the error bits from the device and both registers were 0x00.

> i2c=1,2,30,00,00
Test I2C write
I2C write - Slave Addr: 0x30, Register: 0x00, Payload: 0x00
>
> i2c=0,2,30,2C,1
Test I2C read
I2C read - Slave Addr: 0x30, Register: 0x2C, Number of bytes: 1
Received: 0x00
>
> i2c=0,2,30,2E,1
Test I2C read
I2C read - Slave Addr: 0x30, Register: 0x2E, Number of bytes: 1
Received: 0x00

Edit: I found another status register (Page 0, 0x27 - Overflow Flags)

Value: 0xA0 -> bit 7 (Left channel overflow) and bit 5 (Barrel shifter output overflow)

Questions:

1. Do I need to change any DAC3100 register values to account for SPKVDD voltage change?

2. Would the slight differences in I2S frequencies above cause unrecognizable audio or potential overflow?

Thanks,

Derek

Hi Derek,

Thanks for the feedback on the I2C issue.

Regarding your questions, let me add some comments:

• There are no register changes required for different SPKVDD levels.
• It could affect the playback. Actually I'm concerned about your described clocks. Data should be sampled at 44.1kHz but your actual clocks are lower than that for some margin at ~42,5kHz.
  • Is there any way to make the clocks closer to their expected values? ie 44.1kHz,1.4112MHz and 11.2896MHz?
  • How did you calculated your PLL values? It mentions DAC_FS = 8kHz. Although even by calculating DAC_FS using those values the DAC_FS is ~113kHz instead of 44.1kHz
  • You could try with the following clock settings:
    • PLL_P = 1
    • PLL_R = 2
    • PLL_J = 40
    • PLL_D = 0
    • NDAC = 4
    • MDAC = 4
    • DOSR = 128

Best regards,
-Ivan Salazar
Applications Engineer

Hey Ivan,

I actually inherited this code and used it as is since it is working on previous hardware. It looks like the PLL constants are modified after initial configuration based on the played audio file frequency. For 44.1 KHz, the updated PLL settings are the following:

44100, 
{ 
    0x00, 0x00,   // page 0
    0x05, 0x11,   // set PLL for DAC_FS=44.1KHz: J=8, R=1, D=0, P=1
    0x06, 840,     
    0x05, 0x92,   // power on PLL
    0xFE, 10,     // delay 10 ms
    0x0B, 0x84,   // NDAC=1
    0x0C, 0x94,   // MDAC=16
    0x0D, 0x00,   // DOSR=128
    0x0E, 0x80,
    0xFF
}

// "D" was previosuly configured as 0 (Zero)

I tried your settings and have the same result in that the speaker squeals. Reading register 0x27 still returns a value of 0xA0 -> bit 7 (Left channel overflow) and bit 5 (Barrel shifter output overflow). I created an excel sheet to configure the PLL. After plugging in your recommended values, DAC_FS comes out to be 441 KHz instead of 44.1 KHz. This can be seen in your table above.

To calculate PLL_CLK, I am using equation 6 on page 54 of the DAC3100 datasheet:

Where:

PLL_CLKIN = MCLK = 10870000 on the new hardware

R = 1 , J = 8, D = 0, P = 1

Plugging all this in gives the following:

PLL_CLK = 10870000 * 8 / 1 = 86960000 or 86.96 MHz

To calculate DAC_fs, I am using equation 5 on page 52 of the DAC3100 datasheet:

Where:

NDAC = 1 , MDAC = 16 , DOSR = 128

CODEC_CLKIN = PLL_CLK = 86960000 or 86.96 MHz

Plugging all this in gives the following:

DAC_fs = 86960000 / (1 * 16 * 128) = 42460.9 or 42.4609 KHz which is really close to WCLK of 42.62 KHz.

Regarding getting the clocks closer to the expected values of 44.1kHz,1.4112MHz and 11.2896MHz, I will investigate this. I am using a STM32L4 with a 16 MHz crystal with a flexible PLL so it may be possible. If not, I will have to use the DAC PLL accordingly. I have attached the excel file I am using to calculate PLL values.

Questions

1. Is the 441 KHz value an error in your table or am I missing something?

2. How close does DAC_fs need to be to WCLK? Does this need to be exact?

3. Does WCLK need to be 44.1 KHz, or can it be 42.62 KHz so long as the DAC3100 DAC_fs is also ~42.62 KHz?

4. Does TI have an official calculator for determining PLL divider / multiplier values based on a given MCLK and sampling frequency? This would be a useful tool.

Thanks,

Derek

7411.DAC_PLL_Calculator.xlsx

Hi Derek,

1. I must have input something wrong in my PLL calculator, below is the updated table. Since MCLK/BCLK/WCLK have specific ratio PLL would not be needed.
2. I'm actually more concerned about incorrect clock settings in terms of ratios, than actual resulting frequency. However there is no specification of how close DAC_FS should be to actual WCLK. As long we clocks are matching the ratios for each bit is should be OK
3. As mentioned on point 2 above, it is more important that the ratio from MCLK to BCLK and WCLK is correct, so that each bit and word can be sampled correctly.
4. There is https://www.ti.com/lit/zip/slar163 calculator, you can use TLV320AIC31xx for TLV320DAC3100, their clock structure is similar

I would first try with the clock settings without PLL, if ratios are correct then sampling should be good without using PLL.

However if clocks are not matching correctly, PLL may be helping and could be the reason to use it. Then you can try some configuration to use PLL for correction. The main concern in this case is to make PLL_CLKIN*PLL_R*PLL_J.D/PLL_P > 80MHz and PLL_J > 4

Best regards,
-Ivan Salazar
Applications Engineer

Hi Derek,

Thanks for letting us know about this.
Let us know if you need any further assistance.

Best regards,
-Ivan Salazar
Applications Engineer