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.

TLV320AIC3101: Unable to hear any audio from Jack which is connected via TLV320AIC3101 codec

Part Number: TLV320AIC3101


Hi Team,

I have asked a question related to MCLK, but that question chain got closed. i want to continue that discussion here, please help me to find out the cause.

https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1081746/tlv320aic3101-tlv320aic3101-unable-to-get-mclk-signal

Yes, we need to get MCLK from master side, we are able to get the MCLK 12.288MHz from QCS610(Master), but we are unable to hear any sound from Jac which is connected via TLV codec.

Previously we thought like, the MCLK is only the issue for not hear anything from audio jack. but now we are able to get mclk bclk data line everything as we configured from software side. but we not even hear any noise from audio jack


Please help us to find the cause,

And as you asked earlier ,  have attached the i2cdump output.

  • Hi Adigarla,

    Jeff will be taking a look at the register settings. Looks like you already had a lot of discussion in the other thread. Can you just confirm the other clock rates (BCLK and LRCLK)? Have you verified the data is correctly reaching the device pins by probing the data lines? Apologies if this has been previously discussed.

    Brian

  • Hi Brian, 

    yes we verified all, data bclk lrclk(ws) are comming correctly

  • Hi Adigarla

    Can you clarify for me what your intended signal path is? Are you taking an Analog input to analog output?

    Thank you,

    Jeff

  • Hi Jeff,
    As we are having a DAC in our TI part, our intended signal path must be from Digital input to Analog output.

  • Hi Jeff, 

    we are configuring the 12.288 MHz from master side, are we need to do any modifications in tlv driver code (or) anywhere from tlv side.

    please confirm it.

  • Hi Adigarla,

    It's unlikely it's a driver issue. Can you try the below script? This should set up digital input to output from the headphone jack.

    w 30 07 8A
    w 30 66 A0
    w 30 29 02
    w 30 2B 00
    w 30 25 D0
    w 30 26 20
    w 30 40 80
    w 30 2F 80
    w 30 33 0D
    w 30 41 0D

    Best regards,

    Jeff

  • Hello Jeff, 

    thankyou so much for quick reply,

    We will try these and will reply you soon, and can you reply for my above quarry 
     

    `we are configuring the 12.288 MHz from master side, are we need to do any modifications in tlv driver code (or) anywhere from tlv side.`-->like any register level changes?

  • Hi Adigarla,

    Any changes most likely need to happen TLV side, not driver side. As long as the device is correctly in slave mode, that should be all it needs to accept the clocks sent from the master device.

    Best regards,

    Jeff

  • Jeff, i didn't get your point

    Your telling like we need to do changes on TLV side but not driver side. isn't refers driver side means tlv driver code 

    if not/yes please be tell bit clear, what type of changes we need to do ?

    `that should be all it needs to accept the clocks sent from the master device.`--> we are able to probe out clock signals from qcs610(master), can you say how to know whether the codec is accepting all clocks sent from master device.

  • Hi Adigarla,

    I'm referring to the registers local to the codec. As long as you are using the drivers available from ti.com there should be no need to change the driver. However the codec registers need to be configured correctly. Unfortunately there isn't a good way to check if the clocks are being understood by the codec.

    Best regards,

    Jeff

  • Hi Jeff,

    do you mean the registers local to the codec are pll, k, j etc registers?

    As I already mentioned our driver code is not writing to anything. We configured the pll registers with respect to our MCLK value [12.288 MHz]. From the PLL enabled equation, we got K = 8.000 ie; J=8,D=0000, likewise we given value for the pll registers.

    Also we checked the power sequencing and the reset. We confirmed that the reset is working as per mentioned in the data sheet [appeared after when the codec got all the power]. So we tried manually writing the script for our playback. From our schematics, we are using the HPROUT and HPLOUT for connecting the audio jack. Please help here 

    0 0x00
    1 0x00
    2 0x00
    3 0x81
    4 0x20
    5 0x00
    6 0x00
    7 0x0a
    8 0x20
    9 0x07
    10 0x00
    11 0x82
    12 0x50
    14 0x80
    15 0x10
    16 0x10
    20 0x10
    23 0x78
    26 0x00
    27 0xfe
    28 0x00
    29 0x00
    30 0xfe
    31 0x00
    36 0xcc
    37 0xc0
    38 0xe3
    39 0x00
    40 0x00
    41 0x01
    42 0x78
    43 0x00
    44 0x00
    45 0x00
    46 0x10
    47 0x80
    48 0x00
    49 0x00
    50 0x10
    51 0x9d
    52 0x00
    53 0x00
    54 0x00
    55 0x00
    56 0x00
    57 0x00
    58 0x04
    59 0x00
    60 0x00
    61 0x00
    62 0x00
    63 0x00
    64 0x80
    65 0x9d
    66 0x00
    67 0x00
    68 0x00
    69 0x00
    70 0x00
    71 0x00
    72 0x04
    73 0x00
    74 0x00
    75 0x00
    76 0x00
    77 0x00
    78 0x00
    79 0x00
    80 0x00
    81 0x00
    82 0x80
    83 0x00
    84 0x00
    85 0x00
    86 0x0b
    87 0x00
    88 0x00
    89 0x00
    90 0x00
    91 0x00
    92 0x80
    93 0x0b
    94 0xd8
    95 0x00
    96 0x00
    97 0x00
    98 0x00
    99 0x00
    100 0x00
    101 0x00
    102 0x00

  • Hi Adigarla,

    I'm referring to all registers like the ones you shared. What do you mean by "driver code isn't writing to anything?" How are you configuring things if the code isn't writing?

    I noticed that you have the PLL R value set to 2 which invalidates the clock setup. It needs to be 1 (Register 11)

    Register 38 is writing over reserved registers as well as setting the HPCOM as a feedback with HPL. Try a constant VCM output setting and don't overwrite the reserved portion.

    Register 94 is showing that the HP drivers are not powered. Is that read being taken after the script is run?

    Also did the script I provide not work, or is that tied to this "driver code won't write" issue?

    Best regards,

    Jeff