• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 703 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TAS5766M: TAS5766M severe, repeatable distortion at beginning of streaming, resolves itself after 30 sec

Josh Heiner
Intellectual 860 points
Part Number: TAS5766M
Other Parts Discussed in Thread: SN74CB3Q3257

Hi All,

I'm trying to troubleshoot a TAS5766M board I designed which is running the amp's two channels in parallel mode.  I'm mystified by the presence of severe distortion (sounds like very high THD clipping) that occurs for about 30 seconds after I2S audio data begins to stream to the device.  The distortion begins to gradually diminish about 20 seconds in, and then always resolves itself - the amp sounds great after that.  This behavior is repeatable if I stop the audio stream and start it again.  It's like the amp has to "warm up," but that makes no sense with a class D amplifier.  Other important observations:

1.) Power (12VDC in this case) is constantly applied to the amp, so the behavior is not related to any power up sequencing or the supply being stable.  All that is required to replicate the problem is to start and stop the I2S data stream.

2.) I have a .h register config file which I derived from tuning work in PPC3, but this distortion occurs whether those registers are written to or not.  That is, it happens when the amp is in "naked" mode with the default register values at power up.

3.) The long period of distortion which gradually resolves itself feels like it is related to big RC time constant somewhere but there's no obvious place that would be coming from.  There is no audio path analog circuitry other than the required  AC coupling caps (.1uF film in my case) between the DAC outputs and amp inputs.  I wondered if perhaps this might be related to an internal PLL which is very slow to acquire a lock on the incoming MCLK signal or something like that.

Has anyone else encountered behavior like this?  If so, how did you resolve it?  This is a serious issue for my customer.

Thanks,

Josh

  • 0
    TI__Expert 4300 points

    Hi Josh,

    This isn't behavior, as far as I am aware, which we have witnessed before. If you could, please provide the schematic, layout, and BOM files so that we can have a look at the system. From an audio path perspective, the only sensitive areas in hardware are the DAC_OUT nets and the SPK_AMP_IN nets, but provided you copied the schematic and layout from the EVM for that, it should be fine with little attention paid to it.

    Since you are using it in PBTL mode, I'm wondering if you followed the guidance on the EVM for configuring the input pins of the amplifier, so that the part is properly configured in hardware. I would compare the EVM guidance and your circuit and see if I can spot any differences. The same is true of the output nets. If you followed the EVM guidance, it should be relatively straight forward.

    I actually am wondering if you have something going on in the digital? Are all of the clocks/data stable when the device is brought up? If you have some movement or anomolies in these clock and data lines, it could cause some distortion. Since your'e saying that it sounds like clipping, I would also check the level of the signal coming from the upstream source. Is that being driven within the bounds of the audio path, so that we're not clipping in digital?

    So, I know that's not really a lot to go on, but it's the items I would look at to start with. If you can get the files over that I mentioned above we can put another pair of eyes on it for you.

    Thanks,
    Cody

  • 0 in reply to Cody Dowling
    Intellectual 860 points

    Thanks so much for responding, Cody.  Since posting my problem here, I've been troubleshooting on my own and have found a way to eliminate the problem: previously, I had 2x 330uF low-impedance electrolytic caps on the power rail in addition to the small ceramic bypass caps, and I swapped those for two 470uF caps.  This seems to have taken care of the issue completely, though I've only tried it on one board.  Obviously I need to increase my sample size before I can say I'm confident that this is a true fix.

    What still bothers me deeply is the time constant in play here.  I can understand how inadequate bulk capacitance on the power rail (though I wouldn't have thought 2x 330uF would be inadequate) could cause diminished audio performance, but it seems like that distortion would be relatively constant or at least correlated with peaks in the signal waveform.  I don't at all get what would cause the audio to be distorted for thirty seconds or so only at the beginning of streaming, and then have it go away gradually on its own.  I mean, it can't be the caps charging; that will be effectively instantaneous with a stiff supply rail.  It seems like the amount of rail capacitance interacts with the class D output stage in some way as to produce this result, though I don't know what it would be since the details of the architecture are proprietary.  I could only guess that it is something to do with the closed-loop aspect of the design.

    To try to get to the bottom of this, I designed and built a little test rig I can plug my modules into which allows me to switch both the power and signal sources on the fly.  I'm certain there's nothing wrong with the signal, because when the amp is playing fine, I need only switch the I2S lines to an input with nothing on it, and then switch it back to the original source after a few seconds, and the distortion is instantly present again.  It's the act of having a signal present, then absent, then present again which consistently produces this phenomenon.  If there were something wrong with the I2S signals generally - timing margins or jitter or what have you - then I would expect this distortion to be present all the time, or at least correlated with something other than me arbitrarily pushing a button to switch input sources.

    Regardless, I would very much appreciate a design review with you to see if there are other issues I might have missed.  How can I share the design files with you confidentially?

    Thanks,

    Josh

  • 0 in reply to Josh Heiner
    Intellectual 860 points

    Cody,

    It appears I jumped the gun in thinking the additional rail capacitance was a fix; I've tried the mod with two more boards now and they're exhibiting the same start-of-stream distortion as before.

    I'm back to being mystified by this problem.  If I have any more observations of significance I'll post them here.

    I look forward to doing this design review with you ASAP.

    Josh

  • 0 in reply to Josh Heiner
    TI__Expert 4300 points
    Hi Josh,

    Thanks for the reply and additional info. Actually, adding more/different capacitance to the PVDD nets wouldn't have made any sense to me. We frequently run these amplifiers with as low as 4.7uF of SMT X7R capacitance and they do just fine, given even a mediocre power supply design.

    I am still suspecting there is something about the way the signals in the I²S stream "come-up". Now that we understand there is a test fixture in the path between our device and the signal source, I would ask whether or not the digital lines were buffered before or after they passed through the board to board connection. Also, what does the return path look like for those signals? Can you get some screen captures of those signals to see if they are in compliance with the timing specs?

    Regarding switching on/off the signals, I am curious if the instantaneous loading of the source signals is causing some issue. I think this can be avoided if you follow the start-up/shut-down procedure carefully, but toggling them on/off without that sequence may be the culprit.

    If you would like to put your items on a drop box or sharing directory somewhere, I can access them there. Otherwise, you can post them here and I can delete them after I've retreived them, if you're comfortable with that?

    Please let me know if that works for you.
    Cody
  • 0 in reply to Cody Dowling
    Intellectual 860 points

    Thanks Cody - good to know that changing the rail PDN doesn't make any sense to you either in terms of being the root cause.

    Regarding how the signal switching is done, the lines are switched and buffered with one of your devices: the SN74CB3Q3257.  The four output lines of this device a fed through 33 ohm termination resistors (probably not needed but included for completeness) and very short traces to the amp module, which also has a short paths to the part itself.  The amp module is a four layer design and has generous ground planes, vias, and pins down to the motherboard for return.

    Because we've seen this phenomenon in the end product where there is only one dedicated set of signals and no switching, it's hard for me to believe that the switching itself is the cause.  The main point of this test fixture setup was to be able to switch between a known good set of signals and the ones coming from the end product in order to isolate where the problem was coming from.  Nevertheless, it will be an easy matter to force an arbitrary power down / up sequence when switching input signals, because I have full control over the main rail via a high-side switch.  The 3.3V DVDD supply is derived from the main PVCC rail with a local, low-noise LDO, and there's no enforced sequencing, but the datasheet says on page 47 that "there is no requirement for sequencing of DVDD and PVCC, either supplies can ramp first."  So I do need some clarification about what you mean when you talk about sequencing - are you referring to figure 32 of the datasheet?  If so, I infer that I should either power down the part and power it up again to invoke its internal reset prior to applying I2S signals, or else invoke a software reset to accomplish the same thing.  It doesn't yet make sense to me that what I'm observing would be caused by improper sequencing, because this happens if I switch the inputs to a source with no signals, wait a few seconds, and switch back to the source with I2S signals present.  The datasheet says this on page 33:

    This suggests to me that I should be able to do exactly the sort of signal switching that seems to cause the distortion.  In the end product, it will often be the case that audio signals are present for a time and then go away.  If we need to execute some particular set of commands prior to having signals become active again then I'd definitely want to understand that, but my reading of the datasheet doesn't seem to indicate that this is necessary.

    I can capture some I2S signal waveforms later tonight to share.  As for sharing full details of the design implementation, I'm not at liberty to post them in a public forum.  I could upload them to a Dropbox or something similar, but then how would I share that location with you privately?

    Josh

  • 0 in reply to Josh Heiner
    TI__Expert 4300 points
    Please send them to this address: cody.dowling@ti.com