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.

TLV320DAC32: Audio output is blocked, the chip seems to be locked

Part Number: TLV320DAC32
Other Parts Discussed in Thread: REG101, REG102,

On a custom board, chip is used as jack analog audio output. MCLK is not used, just BCLK:

We connect external powered speakers. During audio playback, we switches off and on the speakers' power. After a certain amount of tries, the chip doesn't output any audio. The processor continues to playback, and all the registers of the chip have exactly the same value as when it worked. If we do a soft reset + reconfigure all the registers which have changed their value by the reset, the chip comes back (without stopping the processor playback), and audio outputs again. So the bug is inside the chip.

I suppose there are glitches in power when we switch speakers off/on, and sometimes, something is blocked inside the chip, why not. But the problem is that we can't detect it by software, because all the registers have the same value. I think that perhaps the PLL is unlocked, but there is no status about it in the registers.

Do you know such troubles ? Are there hidden registers, that we could read, to detect that the chip is not really ready, and we have to reset it again ?

Here is the dump of our registers:

page0 / reg0 = 0x0
page0 / reg1 = 0x0
page0 / reg2 = 0x0
page0 / reg3 = 0x91
page0 / reg4 = 0x80
page0 / reg5 = 0x0
page0 / reg6 = 0x0
page0 / reg7 = 0x8a
page0 / reg8 = 0x0
page0 / reg9 = 0x0
page0 / reg10 = 0x0
page0 / reg11 = 0x1
page0 / reg12 = 0x5
page0 / reg13 = 0x0
page0 / reg14 = 0x0
page0 / reg15 = 0x0
page0 / reg16 = 0x0
page0 / reg17 = 0x0
page0 / reg18 = 0x0
page0 / reg19 = 0x0
page0 / reg20 = 0x0
page0 / reg21 = 0x0
page0 / reg22 = 0x0
page0 / reg23 = 0x0
page0 / reg24 = 0x0
page0 / reg25 = 0x2
page0 / reg26 = 0x0
page0 / reg27 = 0x0
page0 / reg28 = 0x0
page0 / reg29 = 0x0
page0 / reg30 = 0x0
page0 / reg31 = 0x0
page0 / reg32 = 0x0
page0 / reg33 = 0x0
page0 / reg34 = 0x0
page0 / reg35 = 0x0
page0 / reg36 = 0x0
page0 / reg37 = 0xd0
page0 / reg38 = 0xc
page0 / reg39 = 0x0
page0 / reg40 = 0x0
page0 / reg41 = 0x0
page0 / reg42 = 0x50
page0 / reg43 = 0x5a
page0 / reg44 = 0x5a
page0 / reg45 = 0x76
page0 / reg46 = 0x76
page0 / reg47 = 0x80
page0 / reg48 = 0x76
page0 / reg49 = 0x76
page0 / reg50 = 0x76
page0 / reg51 = 0xf
page0 / reg52 = 0x76
page0 / reg53 = 0x76
page0 / reg54 = 0x76
page0 / reg55 = 0x76
page0 / reg56 = 0x76
page0 / reg57 = 0x76
page0 / reg58 = 0x6
page0 / reg59 = 0x76
page0 / reg60 = 0x76
page0 / reg61 = 0x76
page0 / reg62 = 0x76
page0 / reg63 = 0x76
page0 / reg64 = 0x80
page0 / reg65 = 0xf
page0 / reg66 = 0x76
page0 / reg67 = 0x76
page0 / reg68 = 0x76
page0 / reg69 = 0x76
page0 / reg70 = 0x76
page0 / reg71 = 0x76
page0 / reg72 = 0x6
page0 / reg73 = 0x0
page0 / reg74 = 0x0
page0 / reg75 = 0x0
page0 / reg76 = 0x0
page0 / reg77 = 0x0
page0 / reg78 = 0x0
page0 / reg79 = 0x0
page0 / reg80 = 0x0
page0 / reg81 = 0x0
page0 / reg82 = 0x0
page0 / reg83 = 0x0
page0 / reg84 = 0x0
page0 / reg85 = 0x0
page0 / reg86 = 0x0
page0 / reg87 = 0x0
page0 / reg88 = 0x0
page0 / reg89 = 0x0
page0 / reg90 = 0x0
page0 / reg91 = 0x0
page0 / reg92 = 0x0
page0 / reg93 = 0x0
page0 / reg94 = 0xc6
page0 / reg95 = 0xc
page0 / reg96 = 0x0
page0 / reg97 = 0x0
page0 / reg98 = 0x0
page0 / reg99 = 0x0
page0 / reg100 = 0x0
page0 / reg101 = 0x0
page0 / reg102 = 0xa2
page1 / reg0 = 0x1
page1 / reg1 = 0x6b
page1 / reg2 = 0xe3
page1 / reg3 = 0x96
page1 / reg4 = 0x66
page1 / reg5 = 0x67
page1 / reg6 = 0x5d
page1 / reg7 = 0x6b
page1 / reg8 = 0xe3
page1 / reg9 = 0x96
page1 / reg10 = 0x66
page1 / reg11 = 0x67
page1 / reg12 = 0x5d
page1 / reg13 = 0x7d
page1 / reg14 = 0x83
page1 / reg15 = 0x84
page1 / reg16 = 0xee
page1 / reg17 = 0x7d
page1 / reg18 = 0x83
page1 / reg19 = 0x84
page1 / reg20 = 0xee
page1 / reg21 = 0x39
page1 / reg22 = 0x55
page1 / reg23 = 0xf3
page1 / reg24 = 0x2d
page1 / reg25 = 0x53
page1 / reg26 = 0x7e
page1 / reg27 = 0x6b
page1 / reg28 = 0xe3
page1 / reg29 = 0x96
page1 / reg30 = 0x66
page1 / reg31 = 0x67
page1 / reg32 = 0x5d
page1 / reg33 = 0x6b
page1 / reg34 = 0xe3
page1 / reg35 = 0x96
page1 / reg36 = 0x66
page1 / reg37 = 0x67
page1 / reg38 = 0x5d
page1 / reg39 = 0x7d
page1 / reg40 = 0x83
page1 / reg41 = 0x84
page1 / reg42 = 0xee
page1 / reg43 = 0x7d
page1 / reg44 = 0x83
page1 / reg45 = 0x84
page1 / reg46 = 0xee
page1 / reg47 = 0x39
page1 / reg48 = 0x55
page1 / reg49 = 0xf3
page1 / reg50 = 0x2d
page1 / reg51 = 0x53
page1 / reg52 = 0x7e
page1 / reg53 = 0x7f
page1 / reg54 = 0xff

We tried to activate the output short-circuit detection, but it is not detected, and doesn't change anything.

The trouble is not obvious to reproduce, it depends on the speakers, and we need several OFF/ON. But on our customers side, they use professionnal audio amplifier, and face the same problem, sometimes. We took a very long time to find the origin, but now, we can't go on without your help...

Regards.

Best regards.

  • Hi Innes,

    I'll try to help you find a workaround for this issue.
    There are some things I would like to try:
    - When the issue happens, write the following registers to see if this makes the device return to normal playback:
    Page 0 Reg 37 Bit D6 & D7
    Write 1's to these bits
    Page 0 Reg 51 Bit D0
    Write 1 to this bit
    Page 0 Reg 65 Bit D0
    Write 1 to this bit

    - I would also like to try to write the following and see if the device is able to withstand the speaker ON/OFF transition issue.
    Page 0 Reg 37 Bit D5-D4
    write 10 to these bits
    Page 0 Reg 38 Bit D5-D3
    write 010 to these bits

    - One last thing would be to change the following:
    Page 0 Reg 14 Bit D7
    write 1 to this bit

    Please let me know if any of these helps with the issue.

    Best regards,
    -Ivan Salazar
    Applications Engineer - Low Power Audio & Actuators
  • Hi Ivan,

    I tried your 3 tests after a fail, and i tried the 3 tests together too, but none of them unblocks the chip.

    So for the moment, the only sequence which unblocks it is:

            snd_soc_write(save_codec, AIC3X_RESET, 0x80);
    udelay(100);
    snd_soc_write(save_codec, AIC3X_CLKGEN_CTRL_REG, 0xA2);  // 102
    snd_soc_write(save_codec, AIC3X_PLL_PROGA_REG, 0x91);    // 3
    snd_soc_write(save_codec, AIC3X_PLL_PROGB_REG, 0x80);    // 4
    snd_soc_write(save_codec, AIC3X_CODEC_DATAPATH_REG, 0x8A);   // 7
    snd_soc_write(save_codec, AIC3X_CODEC_DFILT_CTRL, 0x05);     // 12
    snd_soc_write(save_codec, HPLCOM_CFG, 0xD0);     // 37
    snd_soc_write(save_codec, HPRCOM_CFG, 0x0C);     // 38
    snd_soc_write(save_codec, HPOUT_POP_REDUCTION, 0x50);    // 42
    snd_soc_write(save_codec, LDAC_VOL, 0x45);   // 43
    snd_soc_write(save_codec, RDAC_VOL, 0x45);   // 44

    snd_soc_write(save_codec, LINE2L_2_HPLOUT_VOL, 0x76);    // 45
    snd_soc_write(save_codec, PGAL_2_HPLOUT_VOL, 0x76);  // 46
    snd_soc_write(save_codec, DACL1_2_HPLOUT_VOL, 0x80);     // 47
    snd_soc_write(save_codec, LINE2R_2_HPLOUT_VOL, 0x76);    // 48
    snd_soc_write(save_codec, PGAR_2_HPLOUT_VOL, 0x76);  // 49
    snd_soc_write(save_codec, DACR1_2_HPLOUT_VOL, 0x76);     // 50
    snd_soc_write(save_codec, HPLOUT_CTRL, 0x0F);    // 51

    snd_soc_write(save_codec, LINE2L_2_HPLCOM_VOL, 0x76);    // 52
    snd_soc_write(save_codec, PGAL_2_HPLCOM_VOL, 0x76);  // 53
    snd_soc_write(save_codec, DACL1_2_HPLCOM_VOL, 0x76);     // 54
    snd_soc_write(save_codec, LINE2R_2_HPLCOM_VOL, 0x76);    // 55
    snd_soc_write(save_codec, PGAR_2_HPLCOM_VOL, 0x76);  // 56
    snd_soc_write(save_codec, DACR1_2_HPLCOM_VOL, 0x76);     // 57
    snd_soc_write(save_codec, HPLCOM_CTRL, 0x06);    // 58

    snd_soc_write(save_codec, LINE2L_2_HPROUT_VOL, 0x76);    // 59
    snd_soc_write(save_codec, PGAL_2_HPROUT_VOL, 0x76);  // 60
    snd_soc_write(save_codec, DACL1_2_HPROUT_VOL, 0x76);     // 61
    snd_soc_write(save_codec, LINE2R_2_HPROUT_VOL, 0x76);    // 62
    snd_soc_write(save_codec, PGAR_2_HPROUT_VOL, 0x76);  // 63
    snd_soc_write(save_codec, DACR1_2_HPROUT_VOL, 0x80);     // 64
    snd_soc_write(save_codec, HPROUT_CTRL, 0x0F);    // 65

    snd_soc_write(save_codec, LINE2L_2_HPRCOM_VOL, 0x76);    // 66
    snd_soc_write(save_codec, PGAL_2_HPRCOM_VOL, 0x76);  // 67
    snd_soc_write(save_codec, DACL1_2_HPRCOM_VOL, 0x76);     // 68
    snd_soc_write(save_codec, LINE2R_2_HPRCOM_VOL, 0x76);    // 69
    snd_soc_write(save_codec, PGAR_2_HPRCOM_VOL, 0x76);  // 70
    snd_soc_write(save_codec, DACR1_2_HPRCOM_VOL, 0x76);     // 71
    snd_soc_write(save_codec, HPRCOM_CTRL, 0x06);    // 72
  • Innes,

    Another possible test came to my mind while giving a second look at this device documentation. Could you please try the following:
    Page 0 Reg 51 Bit D0
    Write 0 to this bit
    Page 0 Reg 65 Bit D0
    Write 0 to this bit
    Page 0 Reg 51 Bit D0
    Write 1 to this bit
    Page 0 Reg 65 Bit D0
    Write 1 to this bit

    Can you also read Page 0 Reg 94 and Page 0 Reg 95 before and after the issue happens?

    Best regards,
    -Ivan Salazar
    Applications Engineer - Low Power Audio & Actuators
  • It's doesn't change anything.

    Page0, reg94=0xc0, reg95=0x00 (before and after, because none of registers change after the problem).

    Regards.

    Olivier.

  • Olivier,

    If Page 0 Reg 94 = 0xC0, then it would mean that HPLOUT and HPROUT are not powered. Is it really like this during playback?
    In addition, in your original post you included the following in the register dump obtained:
    page0 / reg94 = 0xc6
    page0 / reg95 = 0xc
    The first line would mean that the DAC and HPxOUT are actually powered up. But the second line would mean that there is a short circuit detected on HPxOUT, if there is a short circuit event the output drivers must be power-cycled (off/on).

    Best regards,
    -Ivan Salazar
    Applications Engineer - Low Power Audio & Actuators
  • Sorry, I made a mistake.
    Before your test :
    page0 / reg94 = 0xc6
    page0 / reg95 = 0xc
    After your test :
    page0 / reg94 = 0xc0
    page0 / reg95 = 0x0

    For the short-circuit detection, when page0/reg95=0xc, the audio is OK. We programmed page0/reg38.D2=0, because we thought it was the origin of the problem, but it didn't change anything. With such reg38 programmation, after a short circuit detection, the output should come back normal, no ? Even if we don't clean the status ? What could we test now ?
  • Hi Ivan,

    According to the datasheet, reg95 = 0xc = 0x0c doesn't report a short-circuit detection but just that the HPxCOM are fully powered up.
    Thus, our issue is not due to a short-circuit but something else that we cannot detect for now because all registers have the same values than when all is OK.
    Do you have any idea of what it can be ? What can we try to change in the configuration to be able to detect the issue by software ?

    Regards,
    Olivier.
  • Olivier,

    It's hard to identify what is causing the device to stop working as it can't be recreated and there seems to be not a trustful notification from the registers (which does not seem OK).
    HPxCOM should be disabled as they're not being used. Although from the register settings above these should be already disabled:
    page0 / reg58 = 0x6
    page0 / reg72 = 0x6
    Then why are these showing as fully powered up on Reg 95?

    From the previous post:
    Sorry, I made a mistake.
    Before your test :
    page0 / reg94 = 0xc6
    page0 / reg95 = 0xc
    After your test :
    page0 / reg94 = 0xc0
    page0 / reg95 = 0x0
    So Reg 94 is 0xC6 before and 0xC0 after the test I suggested?

    I would think that this should be related mostly to the output stage, as the issue is being caused by a connect/disconnect of the next stage (external amplifier or speaker), right? So this shouldn't affect DAC or PLL.

    Best regards,
    -Ivan Salazar
    Applications Engineer - Low Power Audio & Actuators
  • Olivier,

    It has been a week since last communication. Did this was finally solved? If you have more questions please respond or create a new thread. You can also share an email address so I can contact you directly if it's better for you.

    Best regards,
    -Ivan Salazar
    Applications Engineer - Low Power Audio & Actuators
  • Ivan,

    No, our issue is not solved. To identify which stage is blocked, I try the following tests:

    - power off / power on the HPxOUT (reg51.d0 and reg65.d0) -> no effect
     
    - power off / power on the xDAC (reg37.d7 and reg37.d6) -> no effect

    - disable / enable the PLL (reg3.d7) -> no effect

    Thus, the only way I found to unblock the chip is a global software reset (reg1.d7). What really does this reset on the different internal blocks ?
    Is it possible to apply it on each block individually ?

    In fact, to solve the issue, I have 2 solutions:
     - change the configuration so that the issue doesn't happen any more
     - change the configuration so that the issue can be detected (and then apply a soft reset to restart the chip)
     
    I need some hint to find what is wrong in the current register's values or doesn't match with our schematic. And the first step is to find which internal block is concerned.

    Regards,

    Olivier

  • I found an other solution (other than a global reset) to unblock the TLV320DAC32:
    just set again theses 5 registers with the value they already have
    reg47 = 0x80 -> route DAC_L to HPLOUT
    reg51 = 0x0F -> power up HPLOUT
    reg64 = 0x80 -> route DAC_R to HPROUT
    reg65 = 0x0F -> power up HPROUT
    reg37 = 0xE0 -> power up DAC_L and DAC_R

    If I don't set again the routing (reg47 and reg64), it doesn't work.
    So I guess that the issue is caused by the loss of the routing from DAC to HPOUT.
    Is there a way to check the status of the internal routing ?
    Reg47 and Reg64 are just for configuring the routing but they don't reflect its current status, do they ?
  • Ivan,
    as there is apparently no way to detect the issue (no reply from you to my last posts), we have implemented the following workaround to avoid the loss of the analog output signal:
    every 10 seconds we write again the 5 registers
    reg47 = 0x80
    reg51 = 0x0F
    reg64 = 0x80
    reg65 = 0x0F
    reg37 = 0xE0

    Our device is working 24 hours a day, 7 days a week. So we need to know if there is any risk of reducing the lifetime of TLV320ADC32 by doing that ?
    Is the number of write cycles limited for the internal control registers (like for a Flash memory) ?

    Thank you in advance for your answer, this is important for us to be sure

    Olivier

  • Olivier,

    Unfortunately I'm not able to find a way to detect the fail you're having. This situation is out of the conventional use for the device so the results might as well be unpredictable.
    There is no information available about a limited number of write cycles, however the number of possible write cycles should be really high.

    Best regards,
    -Ivan Salazar
    Applications Engineer - Low Power Audio & Actuators