TAS5825P-SW: full book, page and register map description somewhere

Hi Sylvain,

The TAS58xx series device employs a ROM+RAM process flow structure. This means some DSP codes from your selected process flow also need to be download from the header file during initialization. For example, the book 0x64 is used to store the DSP code RAM patch. Users should not change and not necessary to care about these codes.

To simplify the dumped lines, please use the dump settings to only select the tuning blocks in use(refer to below screenshot). Also, checking the "include comments" box will help you a lot to understand the dumped codes.

Thanks!

Regards,

Sam

Hi Sam,

thanks a lot for your answer I better understand now. A bit of explanation in the datasheet and/or application note and PurePath Console guide would have been nice anyway. For TAS5825 the only clue I got is in the device configuration table where 5805 is claim to be fixed ROM, so probably in contrary of 5825 which store it's DSP flow in RAM as you mentionned previously in your reply.

Btw I did try the "include comments" option and it didn't help that much, in fact it only generate 50'so comment out of  5000+ entries and only for what seems to be a direct copy of the parameters used in the PPC user interface so probably more for letting a way for PPC to retrieve the parameters than for understanding what exactly is going on...

...per example I did my try with the dsp modules (AGL, Clipping, BQ etc...) all off in the PPC interface and I still get a trace of their respectives parameters in the dump... are they really off with parameters stored but not used or on with neutral parameters...??? By the end the result will be nearly the same but as it can theoricaly impact the performances it would be nice to now.

...I also did choose the "End System I2C Address" according to my End System but have no trace of it in the dump. Instead of that I got a comment about "PCM51xx and TAS5766 targets require the high bit (0x80)"...

So there is no big deal here, I totally understand that  the functionnal part should be ok and the rest are just some kind of details that should not change the fact I will have to implement the whole dump anyway.

To better understand my point the TAS5825 replace a previous codec in our design, and this previous codec has got errors in it's documentation that did block our project. So I became quiet concerned by those little details and lack of information who could hide bigger potential fails. We choose TI as a replacement for it's quality, it's support and it's documentation and those little glitch makes me feel a little bit off on those points.

Thanks again for your answer
Sylvain

See answer above.

Hi Sylvain,

Sorry for the late reply.

Regarding to your question on I2C address, it's expected that not showing in the header file. The I2C address is given by the Soc side during the initialization.

Could you please specify your question with below lines? Sorry but I didn't catch the point...

"..per example I did my try with the dsp modules (AGL, Clipping, BQ etc...) all off in the PPC interface and I still get a trace of their respectives parameters in the dump... are they really off with parameters stored but not used or on with neutral parameters...??? By the end the result will be nearly the same but as it can theoricaly impact the performances it would be nice to now."

Thanks!

Regards,

Sam

Hi Sam,

about I2C addresses :

theres is actually two question about the I2C adress the first in my orignal post concerning the "0x97 adress bug", if you could confirm it... and the second concerning the interface design of PPC, I understand that the address is given by the Soc side during the initialisation and that I need to integrate the header into my own I2C process this is no problem what I don't understand is the existance of this droplist in PPC if it's not used at all in the export. But again non big deal just little oddities that make me nervous with the overall quality of PPC.


about BQ :

Yes sure I can specify... as far as I understand BQ are implemented by a calculation based on 5 coefficient per BQ per Channel and they are stored in the 0xAA Book. In parallel the DSP Flow is stored in RAM, which implies a reupload after each startup, and it also the settings as sets in PPC, because there should be no direct needs to store the frequencies and options of BQ's as the coefficient already make the job.

So there are my concerns :
1. how to speed up the startup process, and in extension how to avoir sendings of unnecessary information...
2. how to customize more than one profile in my final product, let's say per example I will play real time musical mix with my device and that BQ's need some customisation beetween each mix. I can sure get it done first in the master but that's not the point I want to know if I can do it live with the DSP configuration and if yes how to do it without reloading the whole DSP flow ? just changing the coefficients ? trying to compare byte for export with BQ on and BQ off to see what the differences are ? no way but reseting the ram and reloading the 6000 values ?


other little disappointment :

* Mac OS version is totally broken, it crash each time I sign in... and seems no longer in devellopment
* Windows version did install well on my desktop, but I had to reinstall three times on my laptop vm to get it works (1st time crash so no audio driver at the end, 2nd time it ask for uninstall but did not reinstall after cleaning, third time ok)
* Windows version on my vm did not see the Available EVM Apps for one all afternoon... it finally works at evening after 5 hours of regular tries
* Windows version on desktop and vm embended sound player in PPC doesn't recognise many of my WAV files, some are crashing it, I suspect metadata not being understood by the software as the fille which plays doesn't contain any.

what save the day :

* TAS5825P make a wonderfull sound with our application speaker
* the usb driver allow me to use whatever player and sound software I want on windows to test the codec output
* the live dsp flow settings is indeed very usefull

Hello Luis,

thanks a lot for your answer. I'll check this application note 847 as soon as possible.

Concerning the I2C address still looks like a bug or a app design flaw to me. This is what it says

"This App requires TAS5825P (Device Id: 0x97) device on the EVM. Found Device Id: 0x97."

This statement can't be true as 5825P has address 0x98 on the EVM.... (paragraph 3.1 of slau713...)  this is double checked by PPC I2C Monitor which talk to 0x98 and triple checked by chapter 9.5.2 of the 5825P evaluation module where you can see that this chipset address could be 0x98, 0x9A, 0x9C or 0x9E... and even considering the LSB variation it would not match.

This gives us two possibilities : 1. this warning is triggered by default and then should prompt 0x98 address and not 0x97... 2. this warning is mistriggerd because this process is looking for the wrong address... In both case it's a minor bug as it doesn't affect the rest of PPC workflow. By the way this warning doesn't prompt with other evaluation module I got like the 5825MEVM so I would definitely go for possibility #2 here.

Sincerely
Sylvain

Hello there,

finally found some clues for better understanding of this whole DSP configuration process, at least for the biquad configuration.

----------------------------------

STEP 1 :  get the whole DSP uploaded on 5825P RAM, it can be donne with I2C or with and external SPI Eeprom as suggested by Luis. We can also speed up this process by writing succesive register with only one I2C write operation instead of unique byte write operation as suggested by the PPC exports. Those different methods remains to be tested and evaluated.

STEP 2 : using I2C Monitor I was able to see than enabling/disabling the equalizer is made in book 0x8c, page 0x0b, register 0x2c with value 0x00000000 (ON) and 0x00000001 (OFF). As this register is not documented in TI documentation I'm still not sure that this is the only purpose of this register.

PVDD and Clipper seems to have different configuration registers. Hybrid-Pro and DRC make a lot of configuration so further investigation is needed.

STEP 3: using I2C Montitor I was able to see that EQ parameters are indeed set only by their respective coefficient. Turning a EQ off just makes it "All pass" with neutral coefficient. Changing the coefficient is the only step needed to change one eq configuration.

This make the commentaries in PPC export totally useless from the chipset point point of view, as expected... Those commentaries are indeed reflecting the settings made in PPC but are linked to 0x8C book registers that actually doesn't need to be changed when you modifiy the EQ parameters.

----------------------------------

It's now very clear to me that despit very nice intentions and undeniable qualities PPC should be taken with care as it's functionnality are clearly not constant in quality (bad warnings, useless functionnality, unclear comments in export, buggy audio player). It's also clear that the register documentation could be improved instead of beeing dispatched in so many application notes or being relagated on PPC as a unique answer.


So by now I'm still looking for a full book, page and register map description, if it's publicaly available somewhere.