• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 91 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.

TAS6584-Q1: Individual channels enter the FAULT state during playback

Fernando Cavazos
Prodigy 60 points
Part Number: TAS6584-Q1
Other Parts Discussed in Thread: UC3843

Tool/software:

Hi audio team,

While testing an amplifier we have designed around the TAS6584 for car audio applications, we have found that individual output channels will spontaneously enter FAULT under the following conditions:

  1. Playing audio into a 4 Ohm reactive load
  2. Amplifier power is provided by a vehicle battery connected to a car alternator
    1. This arrangement is meant to simulate the electrical system of an automobile
    2. there are four circuits - 4 batteries and 4 alternators that can be run simultaneously
  3. Sufficient time has passed, usually after 20 minutes
  4. Pre-amp gain is turned up slightly i.e. 5dB overlap

Monitoring the TAS6584's status registers that are related to the FAULT state, we can see, at the time that channel transitions from PLAY to FAULT, the following

  1. 0x75 reports less than 65C 
  2. none of the flags in 0x81, 0x8d, 0x8e, or 0x8b are asserted

Other information

  1. PVDD is 35V provided by a boost converter based on UC3843
  2. This issue does not occur, even after long periods of time (and regardless of pre-amp level), when the alternators are switched off or when the amplifier is powered by linear, off-line power supplies

The start-up script we are using:

{ 0x00, 0x00 }
{ 0x7f, 0x00 }
{ 0x00, 0x00 }
{ 0x03, 0x22 }
{ 0x04, 0x22 }
{ 0x44, 0x03 }
{ 0xa0, 0x40 }
{ 0x9d, 0x03 }
{ 0xb0, 0x87 }
{ 0x96, 0x0A }
{ 0x9f, 0x10 }
{ 0xe0, 0x33 }
{ 0xe1, 0x33 }
{ 0x54, 0x02 }
{ 0x5b, 0x00 }
{ 0x5c, 0x00 }
{ 0x03, 0x44 }
{ 0x04, 0x44 }

  • 0
    TI__Mastermind 45085 points

    Hello,

    Since the only thing that you have different is the PVDD and VBAT, I would think it could be a voltage fault.  Please look at register 0x86 for stored voltage fault events.   If you see voltage fault events, you should place an oscilloscope on the PVDD and VBAT and check to for valid on invalid voltages.

    Regards,
    Gregg Scott

  • 0 in reply to Gregg Scott
    Prodigy 60 points

    Hi Gregg,

    Thanks for the reply, I will monitor 0x86 as well.

    Here is a bit more information about our set up:

    • The alternator is run while the amp is connected to the battery so that battery charge is maintained.
    • We have run the same TAS based amplifier sample each time, however, it has been connected to different battery/alternator circuits
    • This amp has been run both by itself with no other amps on the other circuits, and with all other battery/alternators running
      • to be clear these are circuits tied to the same ground bus, but the voltage outputs at each battery are not connected together
    • Battery voltage with alternator running is between 14.3 to 14.6 
    • Nominal battery voltage is 13.6V with alternator off
    • The off-line linear supply voltage output is 14.4V regulated
    • The song being played is Eminem - Business
    • We are cleaning the FAULT state by cycling power to the amplifier - this brings PWRDWN and STNDBY low, and then releases these signals with the correct sequence and timing. The above above script written is then to the chip amp bringing all channels up to the PLAY state.
    • In my testing I have noticed that channel 3 will generally drop first but sequence that the channels drop out varies
  • 0 in reply to Fernando Cavazos
    TI__Mastermind 49740 points

    Hi Fernando

    Kindly share your schematic, we could check it first.

    When this problem happened, please record the register value, including 0x72/0x73, and from 0x80 to 0x8F. We need to make clear which fault been triggered.