• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 436 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.

TLV320AIC3120: Generating BCLK and WCLK from MCLK

Scott Gaetjens
Intellectual 270 points
Part Number: TLV320AIC3120

Hello,

We have the TLV320AIC3120 in a product we've prototyped.  We're working on getting the clocks configured correctly since the part is no longer on the eval board.  On the eval board, BCLK and WCLK are provided through the I2S interface.  BCLK is 2.8224MHz (MCLK / 4) and WCLK  is 44.1kHz (MCLK / 256).  We don't have an I2S interface in our prototype.  On our board, we provide MCLK through an onboard oscillator running at 11.2896MHz.  Could you help me figure out how to configure the appropriate registers to have BCLK and WCLK generated from MCLK and have them set at 2.8224MHz and 44.1kHz?

I'll keep trying to figure it out on my own while waiting for a response.  This is a very urgent issue.

Thanks.

 

  • 0
    Intellectual 270 points

    To clarify, we're using the TLV320AIC3120 as a standalone device with ADC to  DAC loopback enabled (we're writing 0x10 to register 0x1D on Page 0).  I've been trying to reference the clock distribution tree in Figure 7-33 as I attempt to generate an ADC_Fs of 44.1kHz and a DAC_Fs of 44.1kHz using an MCLK input of 11.2896MHz.  Can this be done without providing WCLK and BCLK externally?  

  • 0 in reply to Scott Gaetjens
    TI__Mastermind 26235 points

    Hi Scott,

    To answer your second question, yes you can set the device up to run without a full I2S bus: just an MCLK. I've attached a PLL Calculator tool, with the settings saved for what I think is right for you. This gives a sample rate of 44.1k with an MCLK input of 11.2896MHz.

    The BCLK portion is missing, but you can set BDIV_CLKIN to ADC_CLK and set the divider to 4. See page 69 for extra details.

    5383.Audio_CODEC_ADC_PLL_Calculator.xlsx

    The PLL is a bit of a trial-and-error type of feature, so I'm hoping having the calculator tool will help you better.

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Intellectual 270 points

    That doesn't seem to be working for me.  I'm using a RaspberryPi to write the I2C data to the Codec.  My script is attached.  Can you tell what I'm doing wrong?  The script works when I write to the TLV320AIC3120 on the eval board, but not on my own board.  I'm fairly convinced it's a clocking issue, but maybe you'll see something I messed up.

  • 0 in reply to Scott Gaetjens
    Intellectual 270 points

    I also tried setting the multiplexers so that MCLK gets divided by 4 and output on GPIO1, but I'm not seeing anything on my oscilloscope when I look at GPIO1.

    My thought was I'd divide MCLK down to 2.8224 MHz, output it through GPIO1, then connect GPIO1 to the BCLK input.  That still doesn't solve the WCLK part of the equation, but it would be a start.

  • 0 in reply to Scott Gaetjens
    TI__Mastermind 26235 points

    Hi Scott,

    GPIO1 does not need to be connected to the BCLK Input. In Master Mode, BCLK and WCLK are treated as outputs. The device self-generates those clocks and uses them internally. The WCLK and BLCK pins then are available to drive other target devices in the system.

    If the script works on the EVM but not on your prototype board then it's unlikely anything is wrong with your script. However the PLL is turned off in your script, and the device may be getting it's clocks from the TAS1020B controller on the board. There is an I2S enable pin (Active low) seen in the schematic that enables or disables the TAS1020B from providing I2S clocks. If you apply a 3.3V signal to this pin (using the resistor pad) it will disable the clocks. Then you can supply your MCLK and see if your script works.

    As an additional check, can you monitor the I2C bus to make sure your transactions are being taken? You can also confirm this by reading back your writes performed in the script. That will help confirm it as a clocking problem like you said.

    Best regards,
    Jeff McPherson

  • +1 in reply to Jeff McPherson
    Intellectual 270 points

    This is a secondary issue at this point.  We hacked in a binary ripple counter to divide MCLK down by 4 for BCLK and by 256 for WCLK and got our product working.  That's probably the direction we'll go for production since my efforts at redoing all the clocks when only providing MCLK don't seem to be getting me anywhere.

    I really appreciate all your help on this.  I know I've created a lot of forum posts and you've provided good helpful answers.

  • 0 in reply to Scott Gaetjens
    Intellectual 270 points

    my bad...0x91 would be the correct data to write to register 0x05.