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.

TAS5086 VALID1 and VALID2 Stuck

Other Parts Discussed in Thread: TAS5086, TAS5352

Hello,

We are attempting to use the hard mute feature of the TAS5086 (D6 of System Control Register 2).  The mechanism works for a couple mute/unmute operations, but soon gets stuck and will not change assertion level.

The TAS5086 comes up with D6 and D5 being 11 (Al channels are shut down, VALID1 = 0, VALID2 = 0).  While probing the VALID1 line and alternately writing 01 and 11 to register 0x5, I expect the VALID1 will alternate high and low, respectively.  Here is the sequence I observe:

(1) VALID1 = low (initial state)

(2) write 01, VALID1 = high

(3) write 11, VALID1 = low

(4) write 01, VALID1 = high

(5) write 11, VALID1 = high

At the 5th step, VALID1 is stuck high and will not go low, regardless of what I write.

Any ideas on why this is happening?

Thanks!

  • Hi, Ken,

    I can't find it in the d/s, but this device should have an auto-mute that if there is no input, it goes into mute. I suspect that is what's going on in your case.

    Let me know if you can't find it, and I'll read thru the d/s again or ask one of the guys more familiar with this device about it.

    -d2

  • Hi Don,

    Thanks for your response.  I've read through the datasheet, but didn't see anything about auto-mute.  Regardless, I don't think that is the issue.  Here's why:

    -When VALID1 gets "stuck", it gets stuck high, which is a non-muted state.  (When in hard mute, VALID1 should go low).

    -We've seen this behavior even with valid audio in.

    Any other ideas?

    Thanks,

    Ken

  • Hey Don,

    I still cannot make headway on this issue.  Do you have any information for me?

    Thanks,

    Ken

  • Hi, Ken,

    I've asked my colleague to look into it for you to see if he has any suggestions.

    -d2

  • Hello Ken:

    It may be that 11 is the default state and it only responds to the first 11, i.e. it needs some other events.  Do you have a signal streaming during the writes?  Can you try 01 and 00 instead of 11 for asserting and de-asserting VALID1?  Also, is your back-end TAS5186?  Thanks.

    Best regards,

    Tuan

  • Hello Tuan,

    Thanks for your response.  I'm not sure that I understand, though.  From my initial post, you can see that I am attempting to write to register 0x5 to affect the VALID1 line.  From the initial state (11) I set it to 01to set VALID1 high.  I then alternate between those values, expecting VALID1 to toggle.  Is that not the expected behavior?  

    You asked about signal being present.  I believe that I have tried it with and without signal present, but will do the experiment again.  Would you expect the presence of signal to affect the VALID1 state?

    Thanks,

    Ken

  • I am working with Ken on this issue and last night we confirmed, by capturing the I2C data, that we are indeed performing the same steps each time - but with differing results.  We had a difficult time getting VALID1 to go low even one time, although we did see it toggle 3 times - so it would seem to be somewhat intermittent.

    The writes to the TAS5086 are consistent, but VALID1 only sometimes toggles.  We start with VALID1 initialized to low and the first command to put it high is consistently obeyed.  All subsequent commands to go high or low are ignored, sometimes after it toggles once and sometimes after it toggles 2 or 3 times; but it just stops responding to the command.

    We have the TAS5086 connected to TAS5352L amplifier with no pull resistors on the VALID1 line.  The VALID1 output ties directly to RESET_AB and RESET_CD on the TAS5352.

    Naturally we don't have a lot of time to get this figured out, so any help would be greatly appreciated.  Thanks,

    David

    PS - Ken, please correct me if I misstated anything!

  • Hello David/Ken:

    Register 0x05

    Bit D6 = 1 and D5 = 1 = hard mute on VALID1 and VALID2

    Bit D6=0 and D5 = 1 = VALID1=VALID2=high

    It looks like you've been toggling bit D6.

    Please try to toggle bit D5 = 0, i.e. Bit D6 = 0 and D5 = 0, VALID1=low and VALID2=high.  Or do I miss understand that you need both VALID1=VALID2=0?  VALID1 is used for configuring 2.1 channel.  VALID1 keeps other channels from switching ... The design is meant to use bit D5 to turn on/off VALID1.  It also meant to keep VALID2 switching for minimizing pop noise during start/stop PWM.

    If you need both VALID1 and VALID2 going low, please try writing 0x05 40.  Then you can write 0x05 20 to turn them both high.

    Best regards,

    Tuan

  • Hi Tuan,

    Thanks for your response.  We have not been able to resolve the issue.

    To give you more info, we do not have VALID2 hooked up in hardware, so we are really only concerned with VALID1.

    Here is a rough recreation of the truth table from the datasheet:

    D6 | D5 | Ctrl2 Val || VALID1 | VALID2

    0  | 0  | 0x00      || LOW    | HIGH

    0  | 1  | 0x20      || HIGH   | HIGH

    1  | 0  | 0x40      || ?      | ?

    1  | 1  | 0x60      || LOW    | LOW

    Limitations:

    As you can see, for 0x40 the datasheet only says that the outputs are hard muted; it does not explicitly give the state of VALID1 and VALID2.  Also, the datasheet gives one rule: do not attempt to modify D5 unless D6 is 1.

    Here are the procedures we've tested:

    Procedure 1 - toggling between 0x00 and 0x20: I expect this should toggle VALID1 while leaving VALID2 high.  Toggling D5 is safe here because D6 is 0 always.  When we tried this, VALID1 went toggled high and low, but would not go high again.  Monitoring the I2C line, the TAS5086 is acking the messages, indicating it has received them correctly.

    Procedure 2 - toggling between 0x60 and 0x40: As I mentioned, 0x40 is not defined as it relates to VALID1.  But, it does say that for both 0x40 and 0x60, the outputs are muted, so it is obvious that this won't work for us.  We measured VALID1 and saw that it did not toggle and the outputs remained muted.

    Procedure 3 - toggling between 0x60 and 0x20: Because of the D5 rule and because the state of VALID2 is a don't-care for us, I attempt to toggle between 0x60 and 0x20.  (This is the way we've been trying to do it since the beginning).  As previously reported, the VALID1 line toggles once or twice but then stop toggling.  We've analyzed the I2C to the TAS5086 and verify that it is still acking the requests to change the register, but VALID1 is not changing.

    Procedure 4 - toggling between 0x40 and 0x20: Since the datasheet never says that a value of 0x40 means VALID1 = HIGH, this procedure is simply an experiment.  Again, assuming we need to follow that datasheet's rule of not toggling D5 while D6 is 0, we must create a multi-step procedure.  To go from 0x40 to 0x20 following the rule, we must do 0x40, 0x60, 0x20.  To go from 0x20 to 0x40, we must do 0x20, 0x00, 0x60.  We tested this and saw the the VALID1 line will toggle a couple times but eventually will not toggle, despite acking of I2C messages.  

    In the procedures that we expected to work, it did, but only for a few toggles.  Could we have something else not initialized correctly?

    Thanks,

    Ken

  • Hi, Guys,

    Sorry we dropped the ball on this... Did you get anywhere on this on your end?

    -d2

  • Hi Don,

    No, we couldn't ever get the TAS5086 to work correctly.  We ended up abandoning the use of the VALID lines and instead connected the reset lines to an I/O line on the microcontroller.  It seems to work just fine that way.

    It would be nice to be able to use the VALID lines as they were evidently intended to be used.  But unless you have any concern about doing it the way we're doing it now, we'll probably just push forward using the GPIO to control the amp reset lines.   We did, however, keep the option of being able to use the VALID lines.  We just don't have the time right now to keep chasing it down, unless using some GPIO from the micro is a potential problem.

    Thanks for following up.

    David