TPA3255: Fault only after initial startup

Hello Aidan,

Is this being tested on your system or the EVM? If it's the former can you provide the schematic for your system. Additionally it would be beneficial to probe the PWM output, Input, and the Fault Pin when you are driving the signal before this fault condition

best regards,
Luis

Hi Luis,

It is not the EVM, and unfortunately I do not have a schematic handy for it. I never yet got around to document it. The reason being it is actually a far eastern board that I have modified in various ways. However it does in general follow all the guidelines of the datasheet. In summary, it uses a couple of op-amps to generate the inverted inputs for each channel from two single end sources. It has a TI simple switcher buck converter to generate the AVDD. On the output side it has 2 x 39000uF bulk caps very close to the PVDD pin. The output filters being a faithful copy of the recommended design in the datasheet. Essentially someone in China, took the datasheet, layed out a board, with the correct component values, and did a pretty good job in my opinion. Then they sell on ebay. I cant argue at the price. Over a period of years I have used and abused many of these in my development of various audio systems. 

Don't forget this is TPA3255 so its analog on its input. As I said already this was my first thoughts, that perhaps DC blocking caps on the input side where taking a very long time to settle for some reason, and that I might see a slight imbalance on the input side at startup. This does not seem to be the case. 

Having said this, could you suggest what I might want to look for in term of inspecting PWM output? Clearly it's there :)

It is also difficult to isolate the problem as once it has stopped happening, I can then turn the system off and on again without the fault reoccurring. I need to literally leave it off overnight before it starts faulting again. So yeah is a bit of a PITA. 

All the best

Aidan

Hello Aidan,

I wanted to observe the PWM output behavior during startup and right before the fault condition. What kind of capacitors are you using on the input? have you observed the input cap voltage after initial startup? What is the C_start capacitor you are using, have you modified that in any way?

best regards,
Luis

Hi Luis,

An interesting question. Actually originally the input stage had 10uF electrolytics dc blocking between the opamp and the IC. This caused some problems, and for the life of me I can't exactly remember now what it was. However I ended up replacing these with 10uF MLCC instead. So they are now unpolarised.  

With regard to C_start, are you referring to the bootstrap capacitors? If not please clarify. However the bootstraps are MLCC 33nF and rated accordingly, I have not replaced them as if I am not mistaken any problems with bootstrap undervoltage is a non-latching condition. So I don't think this is relevant. But I'm not sure this is what you mean anyway.

All the best.

Aidan

Ahh okay, C_START. Looking at the datasheet I see now, sorry. Ahh, never looked too close at this, I will investigate. Any recommendations?

I have just read a related thread about C_START. It seems it does have the potential to hold the output stages in an off state without indicating a fault condition. But as I said I'm seeing a fault condition latched. It does not suggest that the startup ramp delay is holding off the device switching or otherwise inhibiting. This is also reinforced by the fact the 1 channel is faulting but the other is working just fine.

Once again, everything I understand about the device would suggest that OC_shutdown it is being erroneously triggered. 

Whilst doing some basic tests yesterday I noticed that the output level needed to cause this fault condition can be very low indeed. To clarify; if I drive no signal apart from noise into the input at startup, it does not fault. If I drive just a relatively low signal just after startup. It faults. This lasts for an undetermined length of time, but its multiple seconds, perhaps even mins. Then if we escape this initial period without faulting. I can then ramp up the input signal and abuse the hell out of the channel for hours and hours without fault.

IMHO, weird. 

Hi Aidan

  Luis will continue help you after back to office.

Hello Aidan,

Is this still an open issue? can you collect waveforms of the output PWM behavior and input when you encounter this fault condition.

best regards,

Luis

Hi Luis,

It is still a problem and no I have not made any further progress. Unfortunately it is very difficult to make the fault occur on the bench. It seems to be that if I drive the amplifier into a dummy load it does not do it. Therefore the only way to trigger the fault is to drive into a real loudspeaker and it is simply too loud to do this in the lab. I am stuck with any further ideas.

Aidan

Hello Aidan,

Have you tried replacing the IC on the board to see if you observe the same behavior, otherwise if possible can you try capturing a waveform capture of the BST caps and output when you see the fault condition.

best regards,

Luis

Hi Luis,

I can try to capture some traces, but could you give me some idea what you could be looking for. In particular the any fault caused by under voltage on the BST caps should AFAIK be a non-latching condition. This would not to correlate with the issues I am facing. 

I agree that finally changing the entire unit could be a successful approach to isolate the issue to the IC or surrounding circuit, but it is a rather brutal approach. I would much sooner, for a number of reason, get to the root cause without this approach.

Aidan

Hi Luis,

Okay so I tried on the bench to capture some PWM output and what I found simply added to my confusion. Initially I set up the amplifier with a 4ohm dummy load. Then removed its heatsink, so that I could get more easily at the output pins. Without the heatsink on the effect was dramatic. Within just a few mS of driving a hard signal into the IC it would fault (latched). Observing the PWM output at this point I would see approx 1mS of switching, the peak level of the PWM signal would dip a little ~ 10% as it pulled hard on the power rail. Then after this initial short period, it appeared to start to randomly switch, very erratically, until after slightly less than 3mS of this behaviour it would latch into fault.  This was highly repeatable. Now here is the unexpected behaviour: as soon as I placed the heatsink back on the IC, the fault condition would no longer happen. Instead the amplifier would happily ride out all high level inputs with CB3C operating successfully through the clipping. The CB3C was determinate and clear, very regular 1/4 speed switching during input peaks and troughs. It looked very neat and clearly worked successfully. I would draw your attention to the fact that the earlier behaviour without the heatsink did not show any CB3C activity. It simply looked like the PWM output was having a random fit with no single switching event clearly defined, instead the random switch events where extremely short in duration and often incomplete. That is they did not even last long enough to swing the output fully between the rails. For the most part the output remained close to the PVDD supply rail.

To add even further to the confusion, when I then removed the dummy load, took the unit outdoors with a real loudspeaker attached, it began to fault again in just the same way that I have already described before. As I mentioned I can not get traces off the IC when a real load is on the amp. But unfortunately it is still doing it. 

Hmmm....any ideas

Aidan

Hello Aidan,

If you are removing the heatsink on this device i would expect abnormal behaviors as there is alot of heat in the device when driving the output that it cannot dissipate through the heatsink so it would likely encounter thermal shutdown very quickly under these conditions.

Have you tried any other speakers to see if you are observing the same behavior? You have have any additional technical information on the Speaker being used. In your previous comments you mentioned you can see the fault trigger even with low output power, could you get a capture with a current probe on the speaker wire. Also how is your dummy load connection differ to the speaker wire, are they similarly gauged wire to support the current output?

Could be possible there is a weak short on your PCB or some PIN. I do still recommend reworking the IC on this board with some fresh samples. Without reviewing the schematic or layout which aren't available it seems, there is limited help that can be provided.

best regards,
Luis

Hi Luis,

Oh what it would be like to work in a lab such as yours :) Sorry I do not have a current probe. So that's not going to happen. However, I took the brutal approach as replaced the entire amplifier with an identical one. 

It has stopped the fault!

This is good news and bad.... I do not like this kind of resolution, as it begs the question about reliability of the ICs. Now of course there could be some other trace issue or component issue of the board as I did not only change the IC. So in this regard TI can side step the blame.

Having said this and to be fair, it is probably something other than the IC, the trouble is I will now probably never know and that's frustrating. I only wish it where possible to get more granular detail from the IC about which protection mechanism was actually tripping. Anyway....

To answer your question. The amp is driving a Faital Pro 15HP1060. This is a 15" pro audio quality nominal 4ohm highly un-compliant bass driver, capable of handling 1000W RMS. Its a tough beast of a loudspeaker to drive and I am using it in a bandpass enclosure where only relatively small excursions are needed but physical robustness is essential. As you might expect all cabling is heavy duty.

I think my takeaway from all this will be simple. Don't trust the amplifier when running heavy loads in BTL mode. I so wish I could pin down what the cause was otherwise, this nagging lack of confidence would never go away.

Thanks

Aidan

Hi Aidan

 Luis will continue check it as soon as back to office, possibly this Friday.