TLV320AIC3254: Sporadic failure causing audio cut-off when changing codec clock settings

Hello Gamli,

I'll loop in on of our product experts but I believe these changes need to occur with the device in a power-down state versus making the changes on the fly.

Hi Collin,

Thanks for your reply, but yes, maybe I should have added some info on that as well. When I do modify the clock settings I always run the following procedure:

• Mute ADC/DAC
• Power down ADC/DAC
• Change PLL (A 50ms delay follows this step that solved a problem I had experienced earlier)
• Set other clock values
• Reprogram the desired mDSP coefficients (if required)
• Power up the ADC/DAC
• Un-mute ADC/DAC

/Gamli

Hi Gamli,

Would you be able to read the status flags to narrow down if it is the DAC or output drivers (HP/LO) that are causing the issue? P0_R37 contains the power up status of the DAC blocks and P1_R63 contains the status of DAC Analog gain blocks. Is it just the playback channel that is muted or is it that both playback and record channels are muted?

I hope you are already following the recommendations in http://www.ti.com/lit/an/slaa425d/slaa425d.pdf with regard to coefficient RAM mirroring.

Best Regards.

Hi,

I am using the system in Adaptive mode, as per the application note recommends in my situation.

When reading the status flags you mentioned, they shows correct state of all DAC flags and DAC Analog gain control when the problem occurs. And regarding the playback and record channels, it seems like it is only the playback that is muted while the record channel works, as the outgoing sound can be heard on the other end.

All other suggestions are very appreciated!

/Gamli

Hi Gamli,

If the DAC blocks and gains are powered up and operating as expected then it appears that the miniDSP process flow is probably muting the audio.

Please try the sample rate changes using the PRB modes instead of miniDSP mode. Do not use biquads to keep the tests simple.

Best Regards.

Hi Gamli,

Did you get a chance to check the system using PRB modes?

Best Regards.

Hi,

Thanks for following up!

I have done it partly, as I need the miniDSP_A for operation, I can only do a simple test using the fixed block processing instead of the miniDSP_D. But then I get the same error. AND I have now observed that this happens even with the record, but not only playback as I stated earlier. That was my mistake!

Currently I'm trying to determine if there is some failure in selecting the I2S source, as when I change the clock settings, I also change the I2S audio source, and want to ensure that the data actually is transmitted to the codec.

Do you have any other idea what might be causing this? As it is very sporadic, only happens ca. every 50th time, it is quite hard to debug.

/Gamli

Hi,

A little update:
I have finished verifying that other parts of the system work as they should and analyzed that the RTOS is behaving as expected.

However, now when I have my attention back on the codec module, I noticed a failure that I am able to read from a flag, P0_R38 which is DAC Flag Register 2. When the failure occurs (very sporadic as mentioned earlier) it reads 0x00 - both left and right DAC PGA gain applied is not equal to gain programmed in control register.

Currently I have tested to power cycle the DAC, setting the volume again and giving it some time slack, but none of which have worked in order to solve this.
Any suggestion regarding this issue is really appreciated!

/Gamli

A follow up question/wondering:

I have noticed that the DAC Flag register 2 needs some time in order to correctly set its value, meaning that if I read its value directly after the modifications and power cycle of the DAC, I do not necessarily get the failure indication, even though it occurred. But if I delay the reading of the flag or read it several times, it eventually sets the bits to failed mode (bit D4 & D0 as 0).

Is there any way of knowing if the flag is actually updated (even though it is updated with the same values)?

PS. I am running with soft stepping disabled on the DAC power settings, so that should not be affecting this.

/Gamli

Hi Gamli,

Sorry to hear about the continued sporadic failures on your system.

I assume the the flag register status update process has some inherent delay to account for soft-stepping delay. Are you able to correlate the failure and status of DAC Flag Register 2 ? Does it hold up for every failure? Does the converse hold up when there is no failure? I am not sure if enabling soft-stepping would help, but please try enabling it to see its impact on failure rates.

Best Regards.

Hi Diljith,

Yes clear correlation between the status of DAC flag register 2 and failure. This is the only way in the software where I can detect the failure, and it does hold up for every failure, and no false positives or true negatives that I have seen (yet).

I have tried soft stepping, that does not seem to impact the failure rate at all. But only increases the time period until I can ensure that the flag has been updated with a stable value for me to detect a failure.

/Gamli

Hi Gamli,

It appears to me that the DAC DSP is not running when the failure occurs. Would you mind sharing the process flow for me to review? There are a few things that I would like to check. I have requested you to connect with me on E2E so that you can share files privately.

Have you considered and ruled out failed i2c/spi transaction causing these failures?

Does the i2c driver check for i2c acknowledgements and report transaction errors? How about out-of-order i2c transactions, caused by race conditions among competing software threads? Could you verify that the device configuration writes resulting in a failed sample-rate switch event are proper? You could use an i2c/spi sniffer for this purpose.

Best Regards.

Hi Diljith,

I do check for acknowledgements and report transaction errors. It does not seem to be the problem, but I have not myself verified that it is actually working correctly and that it is checked everywhere. Competing software threads causing out-of-order i2c transaction is something I have not looked into yet, but a good idea! I will try to do those measurements by sniffing the i2c bus!

But I will send you the process flow files. Thanks for the replies, truly appreciated!

/Gamli

Hi Diljith,

After initial testing it looks like this resolved my problem!

Thank you so much!

/Gamli

Hi,

Just wanted to post a minor update:
Disabling sync mode did not completely eliminate the problem, but it reduced the problem frequency a lot, or from about ca 5% failure rate to about 0.2% failure rate.

Combining my former solution of basically monitoring the DAC flag register 2 and take actions when a failure is detected, and disabling the sync mode, gets the failure rate down to minimum.

Thanks for the support.

/Gamli

Hi Diljith,

No it looks like they have the same signature for the failure this time. I read out DAC flag register 1, DAC flag register 2, DAC Analog Gain Ccontrol flag register, and then Sticky flag register 1. None of them shows any sign of failure except for DAC flag register 2.

/Gamli