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.

TLV320DAC23 - no audio out to headphones

 It seems that the BCK and DIN signals are being AND'd together and then driving pin 18 on the QFN RHD package.  BCK and DIN look perfect on pin 28 and pin 1.  It seems weird that this signal driving pin 18 keeps showing up.  Since the CS pin is being driven I don't believe that my configuration commands are being received correctly.

The layout and circuit configuration have been checked repeatedly.  Any ideas?

  • Hi, Percy,

    That's crazy. Is their power applied to the chip when this happens?

    If CS-z is being driven, how do you know this is happening?

    -d2

  • I was able to stop the CS line from being driven this morning.  In my command string to the DAC I was starting with the reset command 0x1FFF .  I noticed today that the CS line looked good until I sent this command, then it started being driven.  I simply removed the reset command from the setup string and the chip started working and the CS line is no longer being driven.

    I have had numerous conversations with TI engineers on this problem, and they all had copies of my code but said nothing about the CS line being driven after the reset.  I have seen this phenomenon on six different chips.  It is definitely part of the chip's functioning.

    I would appreciate your feedback.

  • I am guessing that this reset command puts the chip into some test mode used in manufacturing.

    It is easy to tell when the CS line is driven.  With pin 18 disconnected the CS line is high, with it connected it is at 1V.

  • CS has an internal pull up that is only active when the Digital Interface Activation Register is set to inactive (ACT=0). This is the default after reset.

    When using software reset, in SPI mode the reset is applied on the rising edge of CS and released on the next rising edge of SCLK. In I2C mode, the reset is applied for the duration of the ADC signal.

  • Pin 19, MODE, is tied directly to Vdd so I should be in SPI mode all of the time.  When I send 0x1FFF to the SPI port the CS pin immediately goes active low.  At that point my CPU can not pull it high again using its CMOS output driver.  I was able to get the CS pin back in high Z by repowering the board.  I am pretty sure that during my testing the DCI input started and stopped multiple times.  I have now built 16 boards with this TI chip and have tested at least 9 of them.  All showed this CS phenomenon.

  • Now that I have been able to keep the CS line in high Z by avoiding the reset command, I am still having a problem with the output sound quality.  There is a strange distortion of the audio signal.  It has a strange bass sound that is overpowering a weak rendition of the music in the background.  I would guess that the audio data is being mis-interpreted but perhaps these two phenomena are related in some way.  The weird behavior of the CS line and the distorted audio out.

  • Once again here is my setup code:

    //    sendDACcmnd(0x1FFF);        // reset
        sendDACcmnd(0x0180);        // mute L line in
        sendDACcmnd(0x0380);        // mute R line in
    //    sendDACcmnd(0x05F9);        // mute L vol
    //    sendDACcmnd(0x07F9);        // mute R vol
        sendDACcmnd(0x05D7);        // set L and R vol
        sendDACcmnd(0x0812);        // analog path
        sendDACcmnd(0x0A00);        // digital path
        sendDACcmnd(0x0E0E);        // data format-slv,16b,i2s
        sendDACcmnd(0x102C);        // sample rate-256fs, normal
        sendDACcmnd(0x1201);        // activate digital interface
        DACPwrUp();

    void    DACPwrUp(void) {
        DACnsel = 0;
        temp16 = 0b0000110000100111 ;     // clk,osc off
        SPI2SendWord(temp16);
    //    __delay_us(4);     //
        DACnsel = 1;
    }

  • Hi Percy,

    The issue is most likely the clocking on the I2S lines. You are in slave mode with an MCLK of 10 mHz resulting in a sample rate of exactly 39062.5 kHz. Unless your LRCK input is at EXACTLY 39062.5 kHz, you will have data errors.

    The SPI lines should not effect the audio once the commands have been sent (unless of course you are changing register values...). 

    Best Regards,

    dave