TAS6584-Q1: TAS6584-Q1: Question on Vpredict/Isense/Aux data on SDOUT, what format are they?

Hi Marc

From your description, seems there's lots of guessing and trying there. Perhaps needn't to try everything. The datasheet has lots of description of SDOUT, starting from page 8.3.2.5.

Firstly, make clear you are using I2S or TDM mode, including FSYNC and SCLK frequency, could choose 8.3.2.5.1 or 8.3.2.5.2 to follow.

Then, what is the data you need form SDOUT. The Vpredict, Isense, or the audio data. Enable the function according to datasheet descriptions, and set the offset the adjust their sequence.

I did get more reasonable data once setting 0x26 for 16 bit data. So I'm 16 bit in and out, how would the various offset (from FSYNC, which for some reasons is called that and BCK in other places) be of use? Wouldn't I just set them all to 0 since I am exactly 16 SCLK in each FSYNC 1/2 cycle (left/right).

No offset is needed or wanted.  Then I do note that once enabled it does take several hundred frames of data before the DSP's seem to actually start populating Vpred. and Isen. data in the SDOUT stream, that is fine just needed to know about that.  Additionally, if reading Vpred. would one then turn off the Isen. enable in register 0x05 to 0 or just leave that on all the time and switch what I get with the other control registers?  And as stated in the data book is Vpredict actually 12 bits then, needs to get masked off with 0x0ffff, and is always a positive value just like PVDD is.

Sorry for all the plugging in values and trying stuff, I was trying to figure out sequences with Pure Pulse Console 3 and what all it does, very confusing since it constantly interrogates registers and them writes to them a bunch, setting the book/page stuff more than I would need too, that is the confusing thing where I need to set that or not to book 0, page 0 to have the documented data book register set that I need to work with.  I guess it doesn't hurt to send that all the time, just takes more Milli-seconds of I2C time to write the extra bytes (at 400Hhz).

Hi Marc

Marc Yaxley said:

I did get more reasonable data once setting 0x26 for 16 bit data.

That register has description says TDM mode, and auxiliary channel group. Could you please make sure you are using TDM mode? 

Marc Yaxley said:

Additionally, if reading Vpred. would one then turn off the Isen. enable in register 0x05 to 0 or just leave that on all the time and switch what I get with the other control registers?

Vpredict and Isense not affecting each other, not fully understand your question.

Marc Yaxley said:

and is always a positive value just like PVDD is.

Not always positive value. Isense and Vpredict all have positive and negative value.

Marc Yaxley said:

I was trying to figure out sequences with Pure Pulse Console 3 and what all it does,

You really need to look at the datasheet, for their using.

Ok, correct, I re-read that section and 0x26 is TDM.  I should have said 0x25 register.   I am using I2S mode, not TDM.

Ok so leaving register 0x05 set to 0x0f for all Isense all the time is ok for Vpredict readings then.

So these readings being measured are the load of the BTL output which can be pos/neg values with

no expected DC offset bias.  Got it.

I see the values I do get are not consistent from channel to channel even though the loads are balanced, so I am thinking

I need to do per-channel scaling and calibration to get them to under 10% accuracy of load estimated readings.

I have been trying to set this up for our product from both the data book (I have full one) and how/what PPC3 does when plunking around with it and logging I2C transactions.

The data book is shy on details of some of the 'book/page' stuff that might me needed.  Also very lacking in what the feedback values I'm reading would range in and what a controlling MCU might have to do to use them for control management.

TI could supply a richer set of application notes and sample code ditties in a download for this device that would get us up and running faster with out all the 'playing around'.  The TAS6424 was pretty simple to get going compared to this amp.  I do like the higher PVDD range as that is why we are moving to the TAS6584 product.

Hi

Marc Yaxley said:

The data book is shy on details of some of the 'book/page' stuff that might me needed. 

Please check below document for DSP related registers. The number is too many, not suitable to put all of them into datasheet. TAS6424E doesn't have a DSP, it is indeed much simple.

 TAS6584 Processflow Register Map 2024-03-12.pdf

Thanks for the reply and DSP register doc.  I hope to steer clear of modifying those and use the reset values.  It is good though to be able to decode when they are used by PPC3 and decide to include those in my driver or not.  I have increased to near the power output levels we will be using and am getting readings on all 4 channels (Vp, Is) that make sense and I just need to scale and adapt them to actual calibrated readings by the speaker loads.  I was initially testing at a way low volume setting and not seeing much deviation at those levels.

One thing, not sure if it's my I2S input sequencing or not, I notice the ISense reading do not go back to zero if at all when I play and remove the speaker wire.  I issue stop play and start again and the reading goes to what it should be instantly (zero).  It appears the DSP reading and returning data to SDOUT needs to have some major state change to bring out a current reading?  Comment?

(This could be a buffering issue by my I2S input from the amp, not sure yet.  I don't have good locked in sync. between the play side output, making I2C reading change settings and my I2S reading input side which could be lagging by several dozens of FSync frames I am thinking.)

After starting 'play' mode there is a delay before actual Vp or Is readings become non-zero and make sense when plotted.  This happens when changing the reading channels or from Vp to Is when playing there is a delay, I should imagine the DSP takes some time to read before it can return the data. This is ok and I will make allowance for this in my driver to delay a bit before using the values coming in the I2S stream from SDOUT, does this sound like what you expect an application to do?

Our application uses two TAS6584's and will route both SDOUT's through an OR gate to one I2S input for the MCU chip.  I will set the one I don't want to read to 0 output in the amp. and read the other, comment?

Doing this sort of toggling and selecting what is on SDOUT appears initially to have delays before good valid data can be used from the line, I'll have to heuristically determine delays for valid data use.

Also reading PVDD from the device register, doesn't read until the amp. is in play for a period, if not playing it seems to hold the previous value when played, correct?  It is also off approx. 2 volts from my power supply display so I'll code in a calibration scale/offset if needed for that, not a big deal.

Making good progress though and with the surprises considered, moving towards the goal for our application at a good clip.

Thanks for any further advice,

Marc Y